View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002257||JEDI VCL||00 JVCL Components||public||2004-10-21 07:53||2004-11-30 11:54|
|Product Version||3.00 BETA 2|
|Target Version||Fixed in Version||3.00 RC 1|
|Summary||0002257: Memory leak in function - DataSetLocateThrough - JvDBUtils.pas|
|Description||If you haven't called <field>.AsString before calling the Dataset "Locate" function this can be a quite serious leak.|
The nested CompareField function inside the DataSetLocateThrough function leaks because it looses reference to 'TField' during the call .AsString and allocs mem on the heap that cannot be released. Changing the nested CompareField function to pass by reference "VAR Field:TField" rather than "value" fixes the problem.
Also in the same function there is a statement
"IF BOF and EOF then exit;"
that causes locate function to fail if there is just one record in the table.
Changed to "If Recordcount = 0 then exit;"
|Additional Information||The only function modified is "DataSetLocateThrough".|
|Tags||No tags attached.|
JvDBUtils.zip (6,014 bytes)
>"IF BOF and EOF then exit;"
This should never be true if there is one record.
|Besides, using IsEmpty is better in either case|
|There is no data allocation in the function, so where is the leak? Beware that most memcheckers will give false positives on certain code constructs, so yu can't trust them 100%|
Please try with the latest zip files and tell us if the problem is fixed. These files are available here:
If we don't hear from you in the next 7 days, we will consider this issue fixed.
I agree BOF/EOF should describe an empty record set, but Locate does not successfully 'locate' a record if there is just one record in the dataset.
Using .AsString allocs a variant the first time it is called, using .AsString without reference to the field component allocs data that the field component cannot release. I seen this leak eat up 70+ MB within a couple of days. I plugged the leak in my source code, I was hoping to get if fixed in the source so I don't have to track and fix it again. You can reproduce by using MemData table and load a dataset then immediately do a locate, empty dataset, reload, do a locate. The longer the string your trying to locate the faster the leak.
|I don't quite understand what the fix fixes, but I can't see that it should affect the component neagtively, so I've committed it to CVS.|
|2004-10-21 07:53||anonymous||New Issue|
|2004-10-21 07:53||anonymous||File Added: JvDBUtils.zip|
||Note Added: 0005446|
||Status||new => feedback|
||Note Added: 0005447|
||Note Added: 0005448|
||Relationship added||related to 0001896|
|2004-11-30 04:27||obones||Note Added: 0005769|
|2004-11-30 05:11||anonymous||Note Added: 0005782|
||Status||feedback => resolved|
||Resolution||open => fixed|
||Assigned To||=> user72|
||Note Added: 0005792|
||Assigned To||user72 =>|