GDB version lazarus / 12-Debugger ---------------------------------------------------------------------- rvk · 2015-03-17 15:46 I've noticed that FPC trunk (i386-win32) (and also Lazarus 1.2.6) comes with version 7.2 of gdb.exe. Is there a reason for this version not being upgraded since 2010? Reason I'm asking is that I get a GDB-crash when exiting a program which used TOpenDialog/TSaveDialog on my dev-machine. When debugging the same in a clean VM it doesn't occur so it must be something with my installation (already tried deleting all shell-plugins without result). Setting DisableLoadSymbolsForLibraries to true does work. But I tried version 7.7.50.20130303-cvs of gdb.exe from CodeTyphon (copied to FPC trunk, which Lazarus uses) and I had no problems with the same example. (CodeTyphon itself also had no problem with the same example.) Now I understand there are also a lot of bugfixes for gdb, but Lazarus/FPC doesn't seem to use these upgrades/updates in standard. Why not? (Maybe too much testing is involved?) Is there an official (or easy) way to get the latest version of gdb.exe (without compiling it myself) or should I just use a copy from somewhere else each time? (or are there any other comments about this?) (edit) I now set the debugger to C:\Dev\gdb\gdb.exe which is a 7.9 version I downloaded. (So no need to copy it everytime) ---------------------------------------------------------------------- Martin_fr · 2015-03-17 17:30 Yes there is a reason, more below. Your crash, most likely (and workaround): http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#internal- error:_clear_dangling_display_expressions If that does not help, then on our sourceforge site, in the win32 section is a GDB 7.7.1. Which is 2nd best after 7.2 As for reasons: http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Bugs_in_GDB * 2nd last entry (17835) and 3rd last (16016) (and readme on sourceforge) are problems in 7.7.1 that 7.2 does not have. * 3rd entry (14018) (and not 100% sure that it is fixed in 7.7.1): 7.3 to 7.6 are unusable. winerr5 means they stop in the middle of the debug session. 7.8.x does crash in the debugger test case. The only issue in 7.2: 2nd in list (10989) Environment. If that is an issue 7.7.1 can be used. As you can see new versions get tested (though there is a bit of a lag sometimes), and the IDE is kept up to work with changes in them. The IDE should currently work with all gdb starting from 6.3 up ---------------------------------------------------------------------- rvk · 2015-03-17 18:21 Yes, as I've mentioned, setting DisableLoadSymbolsForLibraries to true does solve the crash. Because I was unsure if I myself (or my dev-installation) was at fault I looked into the different versions of gdb and found, in this case, versions above 7.2 didn't have the problem. So 10989 is not the only issue with 7.2. It's not a big deal for me but I thought I'd ask. I'll put the GDB 7.7.1 in my C:\Dev\gdb directory and use that one. If that causes problems I can always use the original one with the DisableLoadSymbolsForLibraries switch. Thanks for the explanation. ---------------------------------------------------------------------- Cyrax · 2015-03-17 19:05 This smells like SEH problem or lack of it thereof. You might want to rebuild your version of FPC trunk with -dTEST_WIN32_SEH flag if you are using it for Win32 target. ---------------------------------------------------------------------- Martin_fr · 2015-03-17 19:15 Its not an fpc issue. Its gdb that crashes. Something that gdb 7.2 does not know about win 7 and up.  Well gdb 7.2 is too old fo that. It could be SEH, but it does not have to be. ---------------------------------------------------------------------- rvk · 2015-03-17 22:07 Quote from: Cyrax on March 17, 2015, 08:05:22 pmThis smells like SEH problem or lack of it thereof. You might want to rebuild your version of FPC trunk with -dTEST_WIN32_SEH flag if you are using it for Win32 target. I already tried that this afternoon (at the advise of marcov) and it didn't solve the problem (if I've done it correctly by adding it as a define in fpcdefs.inc and recompiling fpc). That's the reason I went looking for another solution and found the newer gdb's to be without this problem. The problem doesn't occur on a clean system so it has to be something on my dev-system but seeing as the newer gdb's don't give this problem it is most likely something in that 7.2 version in combination with my installed software. ---------------------------------------------------------------------- Cyrax · 2015-03-17 23:35 You should give it as commad line option to make utility, like this Code: [Select]make clean all install OPT="-dTEST_WIN32_SEH" COMPILER_OPTIONS="-dTEST_WIN32_SEH" INSTALL_PREFIX= UPXPROG=echo IDE=1 That line should be executed in the root of the trunk sources. ---------------------------------------------------------------------- rvk · 2015-03-18 08:53 I've done the make-changes (did them in my own install script and removed FPC and let it get a clean trunk copy). The gdb-crash still happens with the TEST_WIN32_SEH changes. So in this particularly instance it is not an SEH problem. I found the Alternative GDB (version 7.7.1) on sourceforge (thanks Martin) which worked. There is a clear description there with known troubles so if it comes to that I can always use the DisableLoadSymbolsForLibraries with version 7.2.