Memory problem adding DateTimeValue values to a DatabaseRow

Databases
1

I have a quite simple app that reads a List of excel file and Writes them to DB.
While it is running I experience a LOT of memory usage, growing to reach 20GB and more!
Slowly removing code, it seems that the problem is when I set a couple of datetime values to the rows.
The problem persists also trying different DB (SQLite and MySQL).
I have setup an app that simply cycles instancing a new DatabaseRow, a couple of DateTime objects and assings them to two fake DateTimeValue Fields.
Every cycle I set everything to nil.
This test app keeps growing its memory usage until very very high values.
Is ita bug or I am doing something wrong?

here the test code (runs in a thread):

var drow as DatabaseRow
var ind as integer
var d1,d2 as DateTime
for ind = 1 to 200000
drow = new DatabaseRow
d1 = DateTime.Now
d2 = DateTime.Now
drow.column(“date1”).DateTimeValue = d1
drow.column(“date2”).DateTimeValue = d2
me.AddUserInterfaceUpdate(“stato” :"database row number " + ind.ToString)
d1 = nil
d2 = nil
drow = nil
next

2

Christian reported it.

Bug related to DatabaseRow

1 Like
3

also for date class, not just date time:
https://tracker.xojo.com/xojoinc/xojo/-/issues/74734

4

DatabaseRow related, as usual. Probably any content. :wink:

5

One morte thing, that puzzles me
I have tryed:
drow.column(“date1”).StringValue = d1.SQLDateTime
with the same leack problem.

Shouldn’t this point more on a date objects bug than a DatabaseRow object bug?

6

// Nope. 

Var d As New DatabaseRow
Var t As DateTime = DateTime.Now
Var i, mem As Uint64

mem = runtime.MemoryUsed

For i = 1 To 500000
  
  d.Column("n") = "bug"
  
Next

mem = runtime.MemoryUsed - mem

MessageBox "memory use increased "+ mem.ToString+" bytes"

Quit

image
image785Ă—404 30.6 KB

1 Like
7

:+1:

How could this go unnoticed until now?

Just tested on 2022 4.1 with the same problem!!!

8

Lack of enough use probably.

There are people suffering of crashes due to OOM issues they even don’t know the causes, and they restart and continue anyway without finding the issue and reporting.

1 Like
9

should the bug report be changed, isn’t?
I imagine Christian should do this at this point.

10

You should go there and see. We already exchanged info there.

11

Please everyone interested add their :+1: to the issue, so Xojo team sees it is important and sign up for notification emails for that case.

3 Likes
12

Becuase I never use DatabaseRow.

1 Like
13

what you use?

thank you

14

And… it was fixed for R4. Thank you @William_Yu

3 Likes
15

No QA in xojo. Many users as myself are still using API1. User base is really small and reducing. Looking at the growing pile of bugs, a lot of people decide to just use the work around instead of waste time making a report…

16

You could also say, that such a leak is small enough to stay under the radar.
If it leaks a few hundred bytes per record, you may just not notice it until you get into thousands of records.

Even if the app uses a few GB of memory and the user gets work done and is happy, all that memory is released, when they close the app, before going home in evening.

17

Many people also uses other techniques skipping totally DatabaseRow. Like holding values being worked on in variables, arrays and dictionaries, and pushing them directly into the DB using raw SQL; reading and manipulating the data using RecordSets, that was more stable than DatabaseRow… DatabaseRow seems reached stability by now.
Xojo did not have DatabaseRow for ages, there is a ton of code working without its presence there.

18

Ordinary SQL.