View Issue Details

IDProjectCategoryView StatusLast Update
0037981LazarusDatabase Componentspublic2021-06-17 22:13
ReporterPedro Gimeno Assigned To 
Status newResolutionopen 
Product Version2.1 (SVN) 
Summary0037981: Crash when opening a TCustomBufDataSet descendant with FieldDef's
DescriptionWhen a dataset is being opened, TCustomBufDataSet's InternalOpen calls IntLoadFieldDefsFromFile, which in turn calls FieldDefs.Clear. This frees all the FieldDef's that it contained, but apparently Lazarus has them cached and doesn't have any means to synchronize its cache with the component's FieldDefs list.

As a result of Lazarus using the cached, now freed object, random crashes happen. The backtrace is not very telling, because the problem had already happened earlier when freeing the objects, but it's the one already posted in 0037870. Here's the most relevant excerpt:

#0  INHERITSFROM (self=0x7fffe978f4b8, ACLASS=0x213ba10) at ../inc/
0000001  0x000000000213ba55 in VMT_$CLASSES_$$_TCOMPONENT ()
0000002  0x0000000000435b43 in fpc_do_is (ACLASS=0x12438081, AOBJECT=0x213ba10) at ../inc/
0000003  0x00007fffeca8f755 in ?? ()
0000004  0x0000000001030d53 in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f7a0)
          at componenttreeview.pas:750
0000005  0x0000000001030dcb in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f700)
          at componenttreeview.pas:756
0000006  0x0000000001030dcb in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f660)
          at componenttreeview.pas:756
0000007  0x0000000001030de0 in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f5c0)
          at componenttreeview.pas:757
0000008  0x0000000001030de0 in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f520)
          at componenttreeview.pas:757
0000009  0x0000000001030dcb in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f480)
          at componenttreeview.pas:756
0000010 0x0000000001030ccd in UPDATECOMPONENTNODESVALUES (this=0x7fffed14c010)
          at componenttreeview.pas:762

I'm on the fence about whether this is a problem in Lazarus, or in the FPC database libraries. It's arguably unexpected for a dataset to remove field definitions that the user may have altered, after the form has loaded. However, this lack of persistence (verified) may be considered a separate bug; in that case, the problem would arguably be that Lazarus is not subscribing to FieldDefs notifications in order to keep its cache up to date.

A similar problem might exist with IndexDefs. I haven't checked if it's currently a problem, but if the datasets are allowed to add or remove IndexDefs at any time, to prevent future problems it would be best to do something to sync the IndexDefs with Lazarus' cache.
Steps To Reproduce1. Create a file somewhere with a single line containing a number, e.g. echo 1 > /tmp/test.csv
2. Add a TCSVDataSet to a form or datamodule.
3. Set the filename property to the file created in step 1.
4. Open and close the TCSVDataSet. This creates a FieldDef in the FieldDefs list. Alternatively, create one manually.
5. Ensure you leave the TCSVDataSet, and click it again. This refresh FieldDefs which now shows 1 item.
6. Open the dataset again. If you don't get any crash (possibly in the mild form of an Access Violation window), more iterations of closing/reopening will probably do it. Sometimes it crashes during closing.

If this recipe doesn't work, try saving the form with the FieldDef in it and the dataset closed, then restart the IDE and try opening and closing the dataset several times.
TagsNo tags attached.
Fixed in Revision
Attached Files


has duplicate 0039014 new Lazarus TBufDAtaset: After Setting Up TBufDAtaset, setting acitve to false crashes App/ Lazarus 
related to 0037870 resolvedJuha Manninen Lazarus Access Violation after closing a dataset in the IDE 
related to 0038352 new Packages CSVDataset failure 


Juha Manninen

2020-10-25 10:01

developer   ~0126537

This is most likely also an FPC issue because TCSVDataSet inherits from TBufDataset.
Please test if you can reproduce with TBufDataset.

Pedro Gimeno

2020-10-27 01:13

reporter   ~0126576

After more debugging, I'm now 100% sure that it is a Lazarus issue, in particular with the ComponentTreeView (the one above the properties list). I think it should add an observer for the published properties of the TCollection type, that causes the tree to be rebuilt.

The crashes I'm getting are all related to the tree view, see backtrace. The cached FieldDef's(*) I was talking about are part of the ComponentTreeView.

For the reproduction recipe mentioned above, what's happening is that FieldDefs is being cleared, then rebuilt, but the ComponentTreeView is not updated accordingly, and still holds a cached reference to the (now deleted) old FieldDef's. As soon as something causes an update of the values of the ComponentTreeView without forcing the tree to rebuild, the crash happens.

Here's another way to reproduce the issue with a TBufDataset:

1. Create a TBufDataset.
2. Add some FieldDef's. Set the field type to something, e.g. ftInteger.
3. Right click on it and select 'Create dataset'.
4. Click outside and then click on the dataset again. You should see that there are 2 IndexDef's.
5. Get the tree view's tree to be rebuilt somehow. I triggered that by deleting a FieldDef. That causes the two indexes to appear in the tree.
6. Close the dataset. That causes the two indexes to be deleted. That's standard operation procedure for TBufDataset, you can't really blame it for doing that.

However, now the freed IndexDef's are also being accessed by the tree view, as a result of UpdateComponentNode (I presume that updates values only, without a tree rebuild). That's what causes the crash.

(*) Note: I've tried to separate FIeldDefs, which is a list, from FieldDef, which is an element of the list. I've used FieldDef's to indicate the plural of each element, and FieldDefs to refer to the list itself. That also applies to the OP.

Issue History

Date Modified Username Field Change
2020-10-25 00:15 Pedro Gimeno New Issue
2020-10-25 08:48 Juha Manninen Relationship added related to 0037870
2020-10-25 10:01 Juha Manninen Note Added: 0126537
2020-10-27 01:13 Pedro Gimeno Note Added: 0126576
2021-01-14 14:35 Juha Manninen Relationship added related to 0038352
2021-06-17 22:13 Juha Manninen Relationship added has duplicate 0039014