|
|
I forgot to add the stack trace printed to the terminal when the IDE crashes. Stack trace: $00000000012A6FCA $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/customcontrol.inc $00000000005EED37 PAINTHANDLER, line 4857 of include/wincontrol.inc $00000000005F51DD WMPAINT, line 6850 of include/wincontrol.inc $0000000000610B46 WMPAINT, line 103 of include/customcontrol.inc $0000000000433A11 $00000000005F0C8D WNDPROC, line 5429 of include/wincontrol.inc $0000000000846411 DELIVERMESSAGE, line 112 of lclmessageglue.pas I got one from GDB but it isn't very useful. #0 0x00000000012a6fca in BUFDATASET$_$TCUSTOMBUFDATASET_$__$$_GETINDEXFIELDNAMES$$ANSISTRING () 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. |
|
|
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/objpas.inc:625 625 vmt := vmt^.vParent; (gdb) bt #0 INHERITSFROM (self=0x7fffe978f4b8, ACLASS=0x213ba10) at ../inc/objpas.inc:625 0000001 0x000000000213ba55 in VMT_$CLASSES_$$_TCOMPONENT () 0000002 0x0000000000435b43 in fpc_do_is (ACLASS=0x12438081, AOBJECT=0x213ba10) at ../inc/objpas.inc:42 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/control.inc:2184 0000030 0x00000000006129dd in WNDPROC (this=0x7fffecdb9ff0, MESSAGE=...) at include/wincontrol.inc:5429 0000031 0x000000000049846d in WNDPROC (this=0x7fffecdb9ff0, THEMESSAGE=...) at include/customform.inc:1485 0000032 0x000000000089305e in DELIVERMESSAGE (TARGET=0x7fffecdb9ff0, AMESSAGE=0) at lclmessageglue.pas:112 0000033 0x0000000000752f93 in DELIVERMESSAGE (TARGET=0x7fffecdb9ff0, AMESSAGE=0) at gtk2proc.inc:3734 0000034 0x0000000000766b16 in DELIVERMOUSEDOWNMESSAGE (WIDGET=0x30c5740, EVENT=0x3263e30, AWINCONTROL=0x7fffecdb9ff0) at gtk2callback.inc:2113 0000035 0x0000000000765ce1 in GTKMOUSEBTNPRESS (WIDGET=0x32f2e50, EVENT=0x3263e30, DATA=0x7fffecdb9ff0) at gtk2callback.inc:1835 0000036 0x00007ffff71eb7bc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 0000037 0x00007ffff6912f75 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 0000038 0x00007ffff6924f82 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 0000039 0x00007ffff692d67f in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 0000040 0x00007ffff692dfbf in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 0000041 0x00007ffff73038ac in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 0000042 0x00007ffff71e9f84 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 0000043 0x00007ffff71ea33b in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 0000044 0x00007ffff775dcbc in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 0000045 0x00007ffff66397f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 0000046 0x00007ffff6639a60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 0000047 0x00007ffff6639b0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 0000048 0x000000000052def3 in APPWAITMESSAGE (this=0x7ffff7fb61f0) at gtk2widgetset.inc:2458 0000049 0x00000000004a68c1 in IDLE (this=0x7ffff7fb5bb0, WAIT=true) at include/application.inc:397 0000050 0x00000000004a9929 in HANDLEMESSAGE (this=0x7ffff7fb5bb0) at include/application.inc:1209 0000051 0x00000000004aa1a1 in RUNLOOP (this=0x7ffff7fb5bb0) at include/application.inc:1327 0000052 0x0000000000733e28 in APPRUN (this=0x7ffff7fb61f0, ALOOP=...) at include/interfacebase.inc:54 #53 0x00000000004aa110 in RUN (this=0x7ffff7fb5bb0) at include/application.inc:1315 #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 ... |
|
|
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. |
|
|
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. |
|
|
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). |
|
|
> I have bisected the issue to commit r38353. Lazarus commit or FPC commit? |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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+}
uses
db, sqldb, sqlite3conn;
var
Conn: TSQLite3Connection;
Tran: TSQLTransaction;
SQLQ: TSQLQuery;
begin
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.SQL.Text := 'SELECT * FROM T';
SQLQ.Open;
SQLQ.IndexDefs.Add('IdxSomethingSomethingBlah', '', []);
SQLQ.Close; // crash happens here
end.
[edit: I removed this line: SQLQ.FieldDefs.Delete(0); because it was not actually necessary for reproducing the issue] ObjectInspector-IndexDefCrash.png (17,998 bytes) |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
Ok, resolving. Everybody see the related issues. |
- Anonymous
