Frequent Debugger Error lazarus / 12-Debugger ---------------------------------------------------------------------- simone · 2020-04-18 11:59 With the last two stable versions of Lazarus (2.0.6/8), the debugger very often fails (see attached snapshot) in a project that I have been carrying out for many years without ever having had this problem in the past. Can I prevent this? Thank you. ---------------------------------------------------------------------- Martin_fr · 2020-04-18 12:32 Can you try to get a logfile when the error happens?  https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_de bug_session Looks like Windows? Win 10? 64 bit? Application is native bitness? Same bitness as IDE? ---------------------------------------------------------------------- simone · 2020-04-18 12:36 Quote from: Martin_fr on April 18, 2020, 02:32:01 pmCan you try to get a logfile when the error happens?  https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_de bug_session Looks like Windows? Win 10? 64 bit? Application is native bitness? Same bitness as IDE? The answer to all your questions is yes. I will try to get a logfile when the error happens. Thanks for now. ---------------------------------------------------------------------- Martin_fr · 2020-04-18 12:45 One more question: What debug type info? Dwarf (with sets) or Dwarf 3 So version of GDB (of those tested by me) is entirely crash free. But any version did have more crashes with "Dwarf 3" than with "dwarf /sets" However those errors are common for watch evals. "trying to run/step" would normally not trigger them. Do you have watchpoints? (data breakpoints) Is your app multi-threaded? (and several threads may run the procedure in which you attempt to step) ---------------------------------------------------------------------- simone · 2020-04-18 13:09 In the attached screenshot you can see debugger settings. I don't use break/wash points. The crash happens when the program is launched from the IDE after compilation. The application is single threaded. ---------------------------------------------------------------------- Martin_fr · 2020-04-18 13:52 Quote from: simone on April 18, 2020, 03:09:00 pmThe crash happens when the program is launched from the IDE after compilation. Ah, you could try different setting for the value of "InternalStartBreak" in the property grid (Tools > Options > Debugger...). No favourite value, just try and see. If possible I'd still like to see the log, in case it reveals anything useful to improve the situation. ---------------------------------------------------------------------- jcmontherock · 2020-04-18 14:10 Try to run Lazarus as administrator. ---------------------------------------------------------------------- Martin_fr · 2020-04-18 14:15 Quote from: jcmontherock on April 18, 2020, 04:10:27 pmTry to run Lazarus as administrator. Should only be needed, if you debug an app that itself needs admin privileges. ---------------------------------------------------------------------- simone · 2020-04-18 14:44 Is it possible to enable Log info for debug session from IDE? Just for curiosity. ---------------------------------------------------------------------- Martin_fr · 2020-04-18 15:03 Install the package IDELazLogger. In the Tools menu will be an entry "Logging..." You can set the file there. You can also set the log-enable values. The settings have to be done after each start of the IDE, they are not persistent. You can compile the IDE with defines, to permanently enable the "log- enable" values. Use -dDBG_STATE  to enable DBG_STATE. (and so on) IIRC, you can also put the commandline params into a lazarus.cfg file In the same folder as lazarus.exe, create a file named lazarus.cfg Put 2 lines into it. --debug-log=.... --debug-enable=.... You can check that the logfile is created. (If you end your IDE session, without the error happened, then occasionally delete the log) ---------------------------------------------------------------------- simone · 2020-04-18 15:29 Thanks for the valuable information on the debugger. I will provide my feedback in the hope that they will be useful. ---------------------------------------------------------------------- simone · 2020-04-18 23:17 The attached file is the Lazarus log after the last debugger crash. Thanks for the support. ---------------------------------------------------------------------- Martin_fr · 2020-04-19 00:07 Ok, I was wrong lazarus.cfg only does half of what it should. Darn it. If it happens again, grab the output from menu: view > Ide Internals > debug output (in older IDE it may be under view > "debug windows") Should have some gdb stuff in there. Best if you could open it before starting to debug. (if you have some space on the screen where it wont be to annoying) I am still interested to see if anything can be learned. Though changes are slim, if gdb crashes, there is usually not much to do. So if you want to just try and solve it... read on below. Btw, it looks like 32 bit. At least target exe, probably IDE too? If you want to move on, it may just work with a newer gdb. Go to our SourceForge download page. Chose your Windows (32/64) and look for "Alternative GDB" There should be a GDB 8.2. Alternatively LazDebuggerFp (known as FpDebug) is reasonable functional in 2.0.6/2.0.8 Its quite good in trunk. ---------------------------------------------------------------------- simone · 2020-04-19 08:51 Thanks Martin. Sorry for delay. You are right, my fault. The generated exe is 32 bit, Ide is 64 bit. I will follow your advice and if possible I will provide further details that will emerge. ---------------------------------------------------------------------- Thaddy · 2020-04-19 09:02 There was a really important change regarding GBD: Now gdbmi is used as default, instead of linking against libgdb. This can of course cause side effects, but note it greatly depends of the gdb version on your platform. Can you provide the gdb version you are using? (gdb -version from a terminal) I have gdb 8.2.1 and have no issues, but I know gdb 7.x or older can cause issues. You can always try to build it the old way by specifing gdbmi=0 as a build option. This will try to link in libgdb instead of using the gdbmi interface. Both options require a properly installed gdb. ---------------------------------------------------------------------- simone · 2020-04-19 09:12 Thanks Thaddy. May be I found the problem. I have a separated installation of FPC (32 bit). When I installed Lazarus in the last few times, I didn't notice that he took this version of the compiler. So, I used Lazarus 2.0.8 64 bit with FPC 3.0.4 32 bit. Sorry… I am truly embarrassed. ---------------------------------------------------------------------- Martin_fr · 2020-04-19 09:54 Quote from: Thaddy on April 19, 2020, 11:02:12 amThere was a really important change regarding GBD: Now gdbmi is used as default, instead of linking against libgdb. This statement relates to FPC's textmode ide "fp.exe". And that change has not yet arrived in Lazarus 2.0.8 with fpc 3.0.4. Further more, looking at the image in the original post, this is issue is about using the Lazarus IDE's debugger. (which always has been used gdbmi) ---------------------------------------------------------------------- Thaddy · 2020-04-19 09:59 Quote from: Martin_fr on April 19, 2020, 11:54:12 am (which always has been used gdbmi) AFAIK that "always" is not correct. Rephrase to "long time" seems more appropriate. Anyway: gdbmi is now the standard gdb interface for FreePascal. And the gdb version really matters. ---------------------------------------------------------------------- Martin_fr · 2020-04-19 10:30 Quote from: Thaddy on April 19, 2020, 11:59:03 amAFAIK that "always" is not correct. Rephrase to "long time" seems more appropriate. Anyway: gdbmi is now the standard gdb interface for FreePascal. And the gdb version really matters. right, at first it was plain none mi gdb commands (but not libgdb) Revision: 388  Date: 05 November 2001 01:12:51 Revision: 862 Date: 09 February 2002 02:47:09 Message:  * Upgraded gdb debugger to gdb/mi debugger ---------------------------------------------------------------------- Martin_fr · 2020-04-19 11:32 See also https://forum.lazarus.freepascal.org/index.php/topic,49415.0.html ---------------------------------------------------------------------- Martin_fr · 2020-04-19 12:03 So, I did some tests. If I use Lazarus 2.0.8 (likely other versions too) in the 64bit version and install a 32bit fpc (or cross fpc), but use the 64bit gdb (tested 7.7 and 8.2), then the project does not run in the debugger. From the logs, I can see Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ~"[Thread 420.0x1a4c exited with code 1073741855]\n"=thread- exited,id="2",group-id="i1"=thread-exited,id="1",group-id="i1"=thread- group-exited,id="i1",exit-code="010000000037"This is not reported by the IDE, the app exits silently before even showing a form. This only happens, if using a 64bit gdb for a 32 bit app: 1073741855 = 0x4000001f is STATUS_WX86_BREAKPOINT That is a debug event only occurring in WOW64 (32bit on 64bit). And, indeed gdb (at least up to version 8.2) does not understand this. IIRC, this did not happen in earlier windows versions...(But been around at least a year or two now) While I did not get any gdb crash (nor any error in my debug session / other that the app not starting), it is possible that the same or other gdb versions may crash/err depending on the debugged app. If correctly configured, your gdb path should be: $(LazarusDir)\mingw\$(TargetCPU)-$(TargetOS)\bin\gdb.exe This lets the IDE choose the correct gdb for your apps bitness. (assuming you have the correct gdb installed / the official cross- compile add-on installers contain the required gdb) ---------------------------------------------------------------------- simone · 2020-04-19 14:01 Thanks Martin for your in-depth analysis. I think I was in this situation. Your results explain the crashes that happened to me. Until now I had never studied these aspects because I use the debugger very little. I belong to the old school and I resolve bugs working by hand as long as I can.