diff between Ubuntu's FPC and 'ours'. lazarus / 32-Linux ---------------------------------------------------------------------- dbannon · 2020-02-29 07:20 I see a very strange issue with the tests I have been running on the Beta of Ubuntu 20.04 If I compile my app with the FPC 3.0.4 from the ubuntu repository (be it the U18.04 or U20.04) it works as expected. But if I compile with the FPC 3.0.4 from the Lazarus Sourceforge repo that compiled app will have a little exception at exit when running on U20.04, no problems on earlier distros. The only combination that I see this crash on is Built Using SourceForge Compiler AND Run on U20.04. I have built two VMs (one based on U18.04, one on the beta U20.04) and compiled with both compilers on each, this pattern is quite repeatable. And the crash itself is just as mystifying, see here I have put a couple of debug lines in the FormDestroy handler for the major forms - Code: [Select]Close syncform Close searchform Close settform Closing main form Heap dump by heaptrc unit 21135 memory blocks allocated : 2615144/2661792 21135 memory blocks freed     : 2615144/2661792 0 unfreed memory blocks : 0 True heap size : 393216 True free heap : 393216 An unhandled exception occurred at $00007F1FADCC1073: EAccessViolation:   $00007F1FADCC1073 Did you spot it ?  The crash apparently has happened AFTER heaptrc has counted up all the memory ! And yes, same crash if HeapTRC is turned off. No sign of a problem if I use Qt5. No sign of it using FPC 3.2.0 I have tried some simpler apps and no sign of this pattern so its must be being triggered off by may code somewhere but I have no idea where !   Any suggestions on what to try next ?? Davo ---------------------------------------------------------------------- marcov · 2020-02-29 13:20 run app in gdb and try to get a backtrace (might be as simple as gdb ./app and wait till it crashes, or "bt" after it crashes) ---------------------------------------------------------------------- zeljko · 2020-02-29 13:43 AFAIR there was some problems with some versions of glibc (dynlibs unloading or something like that). ---------------------------------------------------------------------- dbannon · 2020-03-01 22:56 Quote from: marcov on February 29, 2020, 02:20:32 pmrun app in gdb and try to get a backtrace (might be as simple as gdb ./app and wait till it crashes, or "bt" after it crashes) OK, here is the result, I have left my debug messages in the screen scrap to show were its happening, again, its after all the Lazarus forms have closed, after the heaptrace report. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Close syncformClose searchformClose settform[Thread 0x7ffff4ffc700 (LWP 2763) exited]Closing main formHeap dump by heaptrc unit21032 memory blocks allocated : 2587412/263376021032 memory blocks freed     : 2587412/26337600 unfreed memory blocks : 0True heap size : 393216True free heap : 393216 Thread 1 "tomboy-ng" received signal SIGSEGV, Segmentation fault.0x00007ffff43fd073 in ?? () from /lib/x86_64-linux- gnu/librsvg-2.so.2(gdb) bt#0  0x00007ffff43fd073 in  () at /lib/x86_64-linux-gnu/librsvg-2.so.2#1  0x00007ffff74285cf in __GI___call_tls_dtors () at cxa_thread_atexit_impl.c:155#2  0x00007ffff7427d1d in __run_exit_handlers (status=0, listp=0x7ffff75c8718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=    true, run_dtors=run_dtors@entry=true) at exit.c:46#3  0x00007ffff7427d70 in __GI_exit (status=) at exit.c:139#4  0x00007ffff74051ea in __libc_start_main (main=0x7fffffffdf10, argc=0, argv=    0x99e5d0 , init=, fini=, rtld_fini=, stack_end=0xfd126709af25e279)    at ../csu/libc-start.c:342#5  0xfd127676b26be279 in  ()#6  0xfd126709af25e279 in  ()#7  0x0000000000000000 in  ()(gdb) My code does not use any svg capabilities explicitly but I guess there is some in the Lazarus icon handling code ?  The backtrace seems (to my uneducated eyes) to point to something going wrong with the threads at exit. Now, my app has no running extra threads at this stage, the problem seems all up stream.  But just how far up stream ? Davo ---------------------------------------------------------------------- Cyrax · 2020-03-02 07:04 Can you rebuild Lazarus without any optimizations enabled (-O- option to disable all optimizations)? ---------------------------------------------------------------------- dbannon · 2020-03-02 07:30 yeah, sure Cyrax. I was just heading back to here to mention I have just realized that Lazarus it self is dropping core on exit. So its just a bit more serious. Cyrax, the -O- switch, I am guessing that's an edit of the Makefile ?  Can you save me scrolling through the 3.5k lines of Makefile and point me to just where that edit is, please ? Davo ---------------------------------------------------------------------- MarkMLl · 2020-03-02 08:40 Quote from: dbannon on March 02, 2020, 08:30:01 amCyrax, the -O- switch, I am guessing that's an edit of the Makefile ?  Can you save me scrolling through the 3.5k lines of Makefile and point me to just where that edit is, please ? Unless something's been changed recently you should be able to do something like Code: [Select]make OPT='-O-' all MarkMLl ---------------------------------------------------------------------- dbannon · 2020-03-02 09:09 Yep, thanks Mark, that built so I assume its been passed through to fpc, hmm, should I ? Anyway, it does not appear to have made a difference.  Still get a big crash when I exit out of Lazarus, I have not tried, yet, to build my app, need to resolve some dependencies first.  Here is the console output when Lazarus is closed - Code: [Select]bannon@Focal-VirtualBox:~/bin/Lazarus/fixes_2_0$ ~/bin/start-laz-fixes SetPrimaryConfigPath NewValue="~/.fixes_2_0" -> "/home/dbannon/.fixes_2_0" Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] PrimaryConfigPath="/home/dbannon/.fixes_2_0" Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] SecondaryConfigPath="/etc/lazarus" Looking for code tools config file:  "/home/dbannon/.fixes_2_0/codetoolsoptions.xml" NOTE: codetools config file not found - using defaults Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-linux-gtk2 New=x86_64-linux-gtk2 Changed: OS/CPU=True LCL=False NOTE: help options config file not found - using defaults LAZARUS END - cleaning up ... Hint: (lazarus) [TMainIDE.Destroy] B  -> inherited Destroy... TMainIDE Hint: (lazarus) [TMainIDE.Destroy] END /home/dbannon/bin/start-laz-fixes: line 3:  5824 Segmentation fault    (core dumped) ./lazarus --pcp=~/.fixes_2_0 Davo