View Issue Details

IDProjectCategoryView StatusLast Update
0037870LazarusDatabase Componentspublic2020-11-17 16:41
ReporterPedro Gimeno Assigned ToJuha Manninen  
Status resolvedResolutionduplicate 
Product Version2.1 (SVN) 
Summary0037870: Access Violation after closing a dataset in the IDE
DescriptionI get an Access Violation after removing FieldDefs that have associated Fields.

This problem is not always reproducible, but tends to happen quite often.
Steps To Reproduce1. Create a sqlite3 database with e.g. sqlite3 /tmp/database.sqlite "CREATE TABLE T(F INTEGER);"
2. Add a TSQLite3Connection, point the DatabaseName to the above file.
2a (optional). Disable sofCreate in OpenFlags to ensure that the file you're opening is the one created in step 1.
3. Add a TSQLTransaction, set the Database to the connection.
4. Add a TSQLQuery, set the Database to the connection, set the SQL property to: 'SELECT * FROM T'
5. Open the SQLQuery (check Active).
Note: After step 5, the FieldDefs are auto-filled but the Property Editor still says "0 items". That's a separate issue.
6. Right click the SQLQuery, select "Edit fields" and add the only field available.
7. Open the FieldDefs and remove the only FieldDef present.
8. Go to the connection, set Connected to False to close both the connection and the SQLQuery.
After step 8, an Access Violation message is shown. If it is not, try setting Connected back to true, or click the SQLQuery.
Additional InformationFurther fiddling with the components in this state often crashes the IDE.

I think I've had problems with this even when not deleting the FieldDefs before the Fields.

Lazarus 1.8.4 is the previous one I was using, and this seems to work fine in it.
TagsNo tags attached.
Fixed in Revision
Attached Files


related to 0037932 resolvedMichael Van Canneyt FPC Dangling pointer left behind when closing a TBufDataset 
related to 0037981 new Lazarus Crash when opening a TCustomBufDataSet descendant with FieldDef's 
related to 0037915 assignedMichael Van Canneyt FPC Access Violation related to IndexDefs 


Pedro Gimeno

2020-10-04 20:04

reporter   ~0126088

Last edited: 2020-10-05 00:03

View 3 revisions

I forgot to add the stack trace printed to the terminal when the IDE crashes.

  Stack trace:
  $0000000000A65CAB GETSTRVALUEAT, line 3128 of propedits.pp
  $0000000000A65C4F GETSTRVALUE, line 3123 of propedits.pp
  $0000000000A694CD GETVALUE, line 4055 of propedits.pp
  $0000000000A66432 GETVISUALVALUE, line 3225 of propedits.pp
  $0000000000A67A50 VALUEISSTREAMED, line 3622 of propedits.pp
  $0000000000A4F972 DRAWVALUE, line 3027 of objectinspector.pp
  $0000000000A4ED23 PAINTROW, line 3109 of objectinspector.pp
  $0000000000A50870 DOPAINT, line 3186 of objectinspector.pp
  $0000000000A50DAE PAINT, line 3230 of objectinspector.pp
  $0000000000610C76 PAINTWINDOW, line 123 of include/
  $00000000005EED37 PAINTHANDLER, line 4857 of include/
  $00000000005F51DD WMPAINT, line 6850 of include/
  $0000000000610B46 WMPAINT, line 103 of include/
  $00000000005F0C8D WNDPROC, line 5429 of include/
  $0000000000846411 DELIVERMESSAGE, line 112 of lclmessageglue.pas

I got one from GDB but it isn't very useful.

0000001 0x0000000000000000 in ?? ()

Edit: Note that the address 12a6fca is the same in the Lazarus-generated stack trace and in the GDB backtrace, so I guess that's actually the stack frame that is missing in the former.

Pedro Gimeno

2020-10-08 20:25

reporter   ~0126152

Last edited: 2020-10-12 20:49

View 5 revisions

I've recompiled the FPC side of units with debug info now, and got a meaningful backtrace from GDB, directly from the first access violation (the one that didn't crash the IDE, but didn't result in a backtrace because it was caught by Lazarus). Here's a bt followed by a bt full:

Program received signal SIGSEGV, Segmentation fault.
INHERITSFROM (self=0x7fffe978f4b8, ACLASS=0x213ba10) at ../inc/
625	                 vmt := vmt^.vParent;
(gdb) bt
#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
0000011 0x0000000000aafc97 in UPDATECOMPONENTVALUES (this=0x7fffed14a8b0)
          at objectinspector.pp:4637
0000012 0x000000000050b2bf in PROPHOOKMODIFIED (this=0x7fffef1a2fd0, SENDER=0x7fffed005a00,
          PROPNAME=...) at main.pp:13324
0000013 0x0000000000acb219 in MODIFIED (this=0x7fffed707580, SENDER=0x7fffed005a00, PROPNAME=...)
          at propedits.pp:6928
0000014 0x0000000000abdc1b in MODIFIED (this=0x7fffed005a00, PROPNAME=...) at propedits.pp:3253
0000015 0x0000000000abdf2b in SETORDVALUE (this=0x7fffed005a00, NEWVALUE=0) at propedits.pp:3316
0000016 0x0000000000ac02d0 in SETVALUE (this=0x7fffed005a00, NEWVALUE=0x1caa740 '(False)')
          at propedits.pp:3915
0000017 0x0000000000a9f48e in SETROWVALUE (this=0x7fffed1430d0, CHECKFOCUS=true, FORCEVALUE=false)
          at objectinspector.pp:1598
0000018 0x0000000000aa0c3a in SETITEMINDEX (this=0x7fffed1430d0, NEWINDEX=-1)
          at objectinspector.pp:1847
0000019 0x0000000000a9e8c0 in SETSELECTION (this=0x7fffed1430d0, ASELECTION=0x7fffedca3d80)
          at objectinspector.pp:1393
0000020 0x0000000000ab0ea7 in REFRESHSELECTION (this=0x7fffed14a8b0) at objectinspector.pp:4870
0000021 0x0000000000ab0cb2 in SETSELECTION (this=0x7fffed14a8b0, ASELECTION=0x7fffee391520)
          at objectinspector.pp:4845
0000022 0x0000000000bf205a in SETSELECTION (this=0x7fffed745360, ASELECTION=0x7fffe92fd840)
          at customformeditor.pp:556
0000023 0x00000000004f7912 in CONTROLSELECTIONCHANGED (this=0x7fffef1a2fd0, SENDER=0x7fffed946c50,
          FORCEUPDATE=false) at main.pp:9539
0000024 0x0000000000c05f64 in DOCHANGE (this=0x7fffed946c50, FORCEUPDATE=false)
          at ../designer/controlselection.pp:2095
0000025 0x0000000000c00533 in ENDUPDATE (this=0x7fffed946c50) at ../designer/controlselection.pp:1006
0000026 0x0000000000c06b60 in ASSIGNPERSISTENT (this=0x7fffed946c50, APERSISTENT=0x7fffecdbbdd0)
          at ../designer/controlselection.pp:2267
0000027 0x0000000000be4c8b in MOUSEDOWNONCONTROL (this=0x7fffecdbaaf0, SENDER=0x7fffecdb9ff0,
          THEMESSAGE=...) at ../designer/designer.pp:2307
0000028 0x0000000000be8741 in ISDESIGNMSG (this=0x7fffecdbaaf0, SENDER=0x7fffecdb9ff0,
          THEMESSAGE=...) at ../designer/designer.pp:3055
0000029 0x0000000000626246 in WNDPROC (this=0x7fffecdb9ff0, THEMESSAGE=...)
          at include/
0000030 0x00000000006129dd in WNDPROC (this=0x7fffecdb9ff0, MESSAGE=...)
          at include/
0000031 0x000000000049846d in WNDPROC (this=0x7fffecdb9ff0, THEMESSAGE=...)
          at include/
0000032 0x000000000089305e in DELIVERMESSAGE (TARGET=0x7fffecdb9ff0, AMESSAGE=0)
          at lclmessageglue.pas:112
0000033 0x0000000000752f93 in DELIVERMESSAGE (TARGET=0x7fffecdb9ff0, AMESSAGE=0)
0000034 0x0000000000766b16 in DELIVERMOUSEDOWNMESSAGE (WIDGET=0x30c5740,
          EVENT=0x3263e30, AWINCONTROL=0x7fffecdb9ff0) at
0000035 0x0000000000765ce1 in GTKMOUSEBTNPRESS (WIDGET=0x32f2e50, EVENT=0x3263e30,
0000036 0x00007ffff71eb7bc in ?? () from /usr/lib/x86_64-linux-gnu/
0000037 0x00007ffff6912f75 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/
0000038 0x00007ffff6924f82 in ?? () from /usr/lib/x86_64-linux-gnu/
0000039 0x00007ffff692d67f in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/
0000040 0x00007ffff692dfbf in g_signal_emit () from /usr/lib/x86_64-linux-gnu/
0000041 0x00007ffff73038ac in ?? () from /usr/lib/x86_64-linux-gnu/
0000042 0x00007ffff71e9f84 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/
0000043 0x00007ffff71ea33b in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/
0000044 0x00007ffff775dcbc in ?? () from /usr/lib/x86_64-linux-gnu/
0000045 0x00007ffff66397f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/
0000046 0x00007ffff6639a60 in ?? () from /lib/x86_64-linux-gnu/
0000047 0x00007ffff6639b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/
0000048 0x000000000052def3 in APPWAITMESSAGE (this=0x7ffff7fb61f0) at
0000049 0x00000000004a68c1 in IDLE (this=0x7ffff7fb5bb0, WAIT=true) at include/
0000050 0x00000000004a9929 in HANDLEMESSAGE (this=0x7ffff7fb5bb0) at include/
0000051 0x00000000004aa1a1 in RUNLOOP (this=0x7ffff7fb5bb0) at include/
0000052 0x0000000000733e28 in APPRUN (this=0x7ffff7fb61f0, ALOOP=...) at include/
#53 0x00000000004aa110 in RUN (this=0x7ffff7fb5bb0) at include/
#54 0x00000000004216a7 in main () at lazarus.pp:153
(gdb) bt full
... Cut by Juha. The full backtrace does not give extra information in this case ...

Juha Manninen

2020-10-09 20:00

developer   ~0126190

This is a difficult one because the DB classes are in FPC libs. The fix very likely goes there, too.
Maybe the fcl-db lib should be copied under Lazarus code temporarily to debug it.

Pedro Gimeno

2020-10-10 18:58

reporter   ~0126225

I've been trying to narrow down this issue. I've used a TCSVDataSet to eliminate the extra components. It turns out that the Fields property has nothing to do with it, and probably neither does the FieldDefs. I came up with this recipe:

1. Create a text file, e.g. /tmp/file.csv, with a single ASCII line that says for example '1'.
2. In the IDE, go to the Data Access tab and add a TCSVDataSet to the current form (add a form if you don't have it).
3. Set the filename property to the file created in step 1, e.g. /tmp/file.csv
4. Click Active to set it to True.
5. Click Active again to set it to False.
6. Click on any other property in the Property Editor.

It crashes in step 6 for me. The crucial step appears to be step 5. If I click after opening the dataset (i.e. after step 4), nothing happens. If I save the form with the dataset open, then restart the IDE, then close the dataset from the IDE and click a property, it crashes. So, the title should probably be "Access Violation when closing a dataset in the IDE".

This recipe does not work with the OP's setup (a SQLQuery connected to a SQLite database), therefore it may or may not be the same issue. However, the stack traces look very similar, if not identical.

Pedro Gimeno

2020-10-12 13:39

reporter   ~0126254

Last edited: 2020-10-12 15:56

View 2 revisions

I'm no longer sure it's the same issue. Anyway, a simpler recipe based on the OP is to remove the FieldDef while the dataset is open, then close the dataset; no need for fiddling with Fields (i.e. no need for step 6).

I have bisected the issue to commit r38353 [edit: of FPC, not of Lazarus]. Unfortunately, that's a very large commit (1700 lines of diff).

Juha Manninen

2020-10-12 14:21

developer   ~0126257

> I have bisected the issue to commit r38353.

Lazarus commit or FPC commit?

jamie philbrook

2020-10-12 14:59

reporter   ~0126258

if it makes you feel any better, I just tried that in windows and it put the ide into a lock and at some point shut it down.

 I had to use the task to kill the process.

there has been some changes in string handling with the 3.2.x compiler where code that worked before no longer does, it got me on some dll files

 one of them was the use of writing back to a string within the parameter call via VAR parameter where the procedure was marked as inline, it generated bad code.

 its most likely an empty string (nil) being accessed before its checked in some Boolean operation etc.

not sure what the laz is built in for OP levels but until the compiler gets fixed it's best to not go over O2.

Pedro Gimeno

2020-10-12 15:57

reporter   ~0126259

Last edited: 2020-10-12 16:02

View 2 revisions

Sorry, FPC commit. I edited but I was too late.

The commit is about allowing multiple IndexDef's.

ETA: Since I had quite some trouble matching a Lazarus version with a FPC version while bisecting, let me inform you that this compiler version works well with Lazarus r57500.

jamie philbrook

2020-10-12 16:37

reporter   ~0126260

yes it uses the 3.0.4 compiler or earlier within the 3.x.x range

here with the trunk it will lock the ide if I simply set active and un-active and play with other properties giving the text file you suggested .

 I think its string related due to the first initial report you posted. looks like an ansistring null issue being used

Pedro Gimeno

2020-10-12 20:43

reporter   ~0126265

Last edited: 2020-10-12 22:14

View 2 revisions

I've noticed several interesting things.

Most importantly, after knowing the commit was about IndexDef's, I tried to add an IndexDef. This results in a crash upon returning to the dataset component, with no need to open the dataset at all.

And regarding the original reproduction recipe, I hadn't notice this before, but see attachment about how the Object Inspector looks like at the time of the crash.

Clearly, the crash happens while the Object Inspector is trying to draw the IndexFieldNames property. Also, IndexDefs is no longer empty at that point (it seems the new IndexDefs appear when opening the dataset).

With the knowledge that IndexDefs are causing trouble, I've managed to create a standalone program that causes an Access Violation. It uses the same database as in the OP. Once again, I'm not sure if it's the same bug.

{$mode objfpc}{$H+}

  db, sqldb, sqlite3conn;

  Conn: TSQLite3Connection;
  Tran: TSQLTransaction;
  SQLQ: TSQLQuery;

  Conn := TSQLite3Connection.Create(nil);
  Conn.Name := 'Conn';
  Conn.DatabaseName := '/tmp/database.sqlite';

  Tran := TSQLTransaction.Create(nil);
  Tran.Name := 'Tran';
  Tran.Database := Conn;

  SQLQ := TSQLQuery.Create(nil);
  SQLQ.Name := 'SQLQ';
  SQLQ.Database := Conn;

  SQLQ.IndexDefs.Add('IdxSomethingSomethingBlah', '', []);

  SQLQ.Close; // crash happens here

[edit: I removed this line: SQLQ.FieldDefs.Delete(0); because it was not actually necessary for reproducing the issue]

Juha Manninen

2020-10-12 21:45

developer   ~0126269

Thanks Pedro Gimeno, your latest standalone program proves the problem is in FPC's libs. It will also be easier to debug for some DB expert.
Could you please create a new report for FPC project. This one can be marked as related to it.
This report already contains too much unrelated Lazarus specific stuff.

Pedro Gimeno

2020-10-12 23:00

reporter   ~0126272

Thanks, reported as 0037915.

By the way, now I believe that the TCSVDataset crash is unrelated. I can't assure it, because it didn't exist in Lazarus as a component at the time of FPC r38352. In any case, I'm almost sure that if it is a separate problem, it's still on the FPC side and not in the Lazarus side. I'll investigate.

Pedro Gimeno

2020-10-25 02:21

reporter   ~0126529

This report turned out to be a mix of three independent crashes: 0037915, 0037932 and 0037981. It confuses all three, so maybe it should be closed and the other issues used instead, because all relevant info posted here has been reposted in the other issues, and the confusion cleared.

Juha Manninen

2020-10-25 09:50

developer   ~0126534

Ok, resolving.
Everybody see the related issues.

Issue History

Date Modified Username Field Change
2020-10-04 19:23 Pedro Gimeno New Issue
2020-10-04 20:04 Pedro Gimeno Note Added: 0126088
2020-10-04 20:09 Pedro Gimeno Note Edited: 0126088 View Revisions
2020-10-05 00:03 Pedro Gimeno Note Edited: 0126088 View Revisions
2020-10-08 20:25 Pedro Gimeno Note Added: 0126152
2020-10-08 20:28 Pedro Gimeno Note Edited: 0126152 View Revisions
2020-10-08 20:33 Pedro Gimeno Note Edited: 0126152 View Revisions
2020-10-09 20:00 Juha Manninen Note Added: 0126190
2020-10-10 18:58 Pedro Gimeno Note Added: 0126225
2020-10-11 11:38 Juha Manninen Note Edited: 0126152 View Revisions
2020-10-11 11:40 Juha Manninen Summary Access Violation after removing FieldDefs that have associated Fields => Access Violation after closing a dataset in the IDE
2020-10-11 11:40 Juha Manninen LazTarget => -
2020-10-12 13:39 Pedro Gimeno Note Added: 0126254
2020-10-12 14:21 Juha Manninen Note Added: 0126257
2020-10-12 14:59 jamie philbrook Note Added: 0126258
2020-10-12 15:56 Pedro Gimeno Note Edited: 0126254 View Revisions
2020-10-12 15:57 Pedro Gimeno Note Added: 0126259
2020-10-12 16:02 Pedro Gimeno Note Edited: 0126259 View Revisions
2020-10-12 16:37 jamie philbrook Note Added: 0126260
2020-10-12 20:43 Pedro Gimeno Note Added: 0126265
2020-10-12 20:43 Pedro Gimeno File Added: ObjectInspector-IndexDefCrash.png
2020-10-12 20:49 Pedro Gimeno Note Edited: 0126152 View Revisions
2020-10-12 21:45 Juha Manninen Note Added: 0126269
2020-10-12 22:14 Pedro Gimeno Note Edited: 0126265 View Revisions
2020-10-12 23:00 Pedro Gimeno Note Added: 0126272
2020-10-13 07:18 LacaK Relationship added related to 0037915
2020-10-25 02:21 Pedro Gimeno Note Added: 0126529
2020-10-25 09:48 Juha Manninen Relationship added related to 0037932
2020-10-25 09:48 Juha Manninen Relationship added related to 0037981
2020-10-25 09:50 Juha Manninen Assigned To => Juha Manninen
2020-10-25 09:50 Juha Manninen Status new => resolved
2020-10-25 09:50 Juha Manninen Resolution open => duplicate
2020-10-25 09:50 Juha Manninen Note Added: 0126534