View Issue Details

IDProjectCategoryView StatusLast Update
0002257JEDI VCL00 JVCL Componentspublic2004-11-30 11:54
ReporteranonymousAssigned To 
Status resolvedResolutionfixed 
Product Version3.00 BETA 2 
Target VersionFixed in Version3.00 RC 1 
Summary0002257: Memory leak in function - DataSetLocateThrough - JvDBUtils.pas
DescriptionIf 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 InformationThe only function modified is "DataSetLocateThrough".
TagsNo tags attached.


related to 0001896 resolved Problems in TjvMemoryData - working on it 


2004-10-21 07:53 (6,014 bytes)


2004-10-22 13:14


>"IF BOF and EOF then exit;"
This should never be true if there is one record.


2004-10-22 13:15


Besides, using IsEmpty is better in either case


2004-10-22 13:18


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%


2004-11-30 04:27

administrator   ~0005769

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.


2004-11-30 05:11

viewer   ~0005782

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.


2004-11-30 11:54


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.

Issue History

Date Modified Username Field Change
2004-10-21 07:53 anonymous New Issue
2004-10-21 07:53 anonymous File Added:
2004-10-22 13:14 user72 Note Added: 0005446
2004-10-22 13:14 user72 Status new => feedback
2004-10-22 13:15 user72 Note Added: 0005447
2004-10-22 13:18 user72 Note Added: 0005448
2004-10-22 13:19 user72 Relationship added related to 0001896
2004-11-30 04:27 obones Note Added: 0005769
2004-11-30 05:11 anonymous Note Added: 0005782
2004-11-30 11:54 user72 Status feedback => resolved
2004-11-30 11:54 user72 Resolution open => fixed
2004-11-30 11:54 user72 Assigned To => user72
2004-11-30 11:54 user72 Note Added: 0005792
2004-11-30 11:54 user72 Assigned To user72 =>