Crash in Object Inspector when opening a TCSVDataSet
Original Reporter info from Mantis: pgimeno
-
Reporter name: Pedro Gimeno
Original Reporter info from Mantis: pgimeno
- Reporter name: Pedro Gimeno
Description:
When 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 #37870 (closed). Here's the most relevant excerpt:
#0 INHERITSFROM (self=0x7fffe978f4b8, ACLASS=0x213ba10) at ../inc/objpas.inc:625 #1 0x000000000213ba55 in VMT_$CLASSES_$$_TCOMPONENT () #2 0x0000000000435b43 in fpc_do_is (ACLASS=0x12438081, AOBJECT=0x213ba10) at ../inc/objpas.inc:42 #3 0x00007fffeca8f755 in ?? () #4 0x0000000001030d53 in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f7a0) at componenttreeview.pas:750 #5 0x0000000001030dcb in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f700) at componenttreeview.pas:756 #6 0x0000000001030dcb in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f660) at componenttreeview.pas:756 #7 0x0000000001030de0 in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f5c0) at componenttreeview.pas:757 #8 0x0000000001030de0 in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f520) at componenttreeview.pas:757 #9 0x0000000001030dcb in UPDATECOMPONENTNODE (parentfp=0x7fffffffc240, ANODE=0x7fffeca8f480) at componenttreeview.pas:756 #10 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 reproduce:
- Create a file somewhere with a single line containing a number, e.g. echo 1 > /tmp/test.csv
- Add a TCSVDataSet to a form or datamodule.
- Set the filename property to the file created in step 1.
- Open and close the TCSVDataSet. This creates a FieldDef in the FieldDefs list. Alternatively, create one manually.
- Ensure you leave the TCSVDataSet, and click it again. This refresh FieldDefs which now shows 1 item.
- 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.
Mantis conversion info:
- Mantis ID: 37981
- OS: Linux
- Build: 64070
- Version: 2.1 (SVN)