Problems running gdb debugger in Lazarus 1.0 & 1.1; Timeouts lazarus / 12-Debugger ---------------------------------------------------------------------- CephasAtheos · 2012-09-27 07:41 G'day all, I'm trying to debug my newly-ported and compiled (yay!) project in Lazarus, but I keep getting into trouble with the debugger. Whenever I hover the mouse over something innocuous like a comment or a reserved word, the debugger tries to debug it, which triggers a timeout. After that, the debugger's pretty much useless, as any mouse pointer movement just keeps tripping the timeout. (I guess I shouldn't comment my code so heavily!  ) I read in some other posts here that turning on bundles can help (I'm running under OSX). So I tried that, and in fact that helps a great deal with valid debug variables (and it actually allows the project to work, which was a hugely frustrating problem initially), but sooner or later, I get the dreaded debug timeout again. But at least I can *start* to debug, which is a great improvement with the bundle option! I've also read that configuring the project to use the dwarf debug option could be helpful. However, after trying all the options, it seems that all the debuggers suffer from the same strange problem. I've tried changing the debug timeout, and played around with the project compilation settings, including turning optimisations off, including valgrind info, basically anything that remotely looks like it has some function in terms of live debugging! But nothing I do seems to change the results. This happened 'out of the box' with FPC 2.6.0 and Lazarus 1.0 RC1, and also happens with FPC 2.7.1 and Lazarus 1.1 (and all the combinations of compiler version and IDE version). I guess in the end I don't mind which debugger works, as long as one works! , But I also want to understand the consequences of using different debuggers - can I keep using the IDE to debug, for example? In the documentation, this isn't mentioned, only the fact that different debuggers allow remote debugging and so on. So I'm "assuming" that all the various provided debuggers will work within the IDE. If anyone has an answer for how to stop the debugger getting its knickers in a twist over non-essential text, or at least where I may look to see how this behaviour could be modified, I'd very much appreciate the pointers. Cheers, Pete ---------------------------------------------------------------------- Martin_fr · 2012-09-27 12:39 As for evaluating comments. This can not be disabled. It is an intended feature. A comment may contain the name of a variable after all. You can disable ALL debug-hint evaluation. (Options/Editor/Completion and Hints: "Show value hints while debugging"). Then you can view variables in the "watch window". ---------- The drop down ("gdb" versus "gdb via ssh") has noting to do with the issue. "gdb via ssh" is an experimental (and not fully working) attempt to allow remote debugging on an other PC.  Further more, even if it was working, it would not help. It uses gdb too. And the issue is caused by gdb. So the "gdb" in the dropdown is the correct option (well it is the only option). The problem is somewhere in gdb  (And the IDE does only support gdb). GDB sometimes misbehaves. No one knows, if gdb's internal session is damaged by this. But so far all reports indicate, that it keeps working afterwards. As indicated there is Mac-Ports. But so far I was unable to get that to run at all. Also, I can only test 32 bit. So I can not test the time-out stuff myself, since it only happens on 64 bit. In fact it was entirely implemented by viewing log-files from others, and then sending those others patches. Things, that could potentially affect the timeouts may be: - stabs versus dwarf (project options / linking) - getting the MacPorts gdb to work But no one yet seem to have succeeded on either. Otherwise: - no smart linking - no optimization, except -O1 http://wiki.lazarus.freepascal.org/Debugger_Setup ---------------------------------------------------------------------- CephasAtheos · 2012-09-27 19:17 That's great information, thanks Martin! In fact, you've confirmed every step I've taken to try and sort this out, which means I'm in the right ballpark, which is a huge relief! Part of the problem for me is that the debugger is failing to stop notifications when WarnOnTImeout is set to false. That's another issue altogether, but it's complicating things, since every time the mouse goes near a comment, or near a calculated value (like SizeOf(ChunkHeader) or whatever), I get the slow, annoying popup messagedlg window telling me the debugger has timed out! So my workaround at the moment is a combination of using Turbo Pascal 3.0-style local variables that I assign my values to in the code (like "dummy_int := SizeOf(ChunkHeader)", or "Filestream.Read(dummy_string); Filestream.seek(0-length(dummy_string))" - yuck!!), or watches, which only work as long as the thing I'm watching isn't in a comment, or all I get is in the watch list. I didn't realise about the debug hint evaluation, that might at least get rid of the annoying timeout windows, of course at the cost of losing the best type of variable examination (hints)... Ah well. I'm looking into the debug interface (ui) source code, but I've had 4 hours' sleep in 2 days and I can hardly focus on this screen at the moment, let alone someone else's sourcecode! But I"ll keep trying! THanks so much for the information, that's really great to know and understand why, as well as how! Cheers, Pete ---------------------------------------------------------------------- Martin_fr · 2012-09-28 02:56 Quote from: CephasAtheos on September 27, 2012, 09:17:23 pmPart of the problem for me is that the debugger is failing to stop notifications when WarnOnTImeout is set to false. That's another issue altogether, but it's complicating things, since every time the mouse goes near a comment, or near a calculated value (like SizeOf(ChunkHeader) or whatever), I get the slow, annoying popup messagedlg window telling me the debugger has timed out! See the other thread. About the speed. Set the timeout to 50. Unfortunately it is the best , that can be done. ---------------------------------------------------------------------- CephasAtheos · 2012-09-28 21:08 Quote from: Martin_fr on September 28, 2012, 04:56:51 amAbout the speed. Set the timeout to 50. Unfortunately it is the best , that can be done. Yeah, see that was just me being emotional...   Sorry, Martin. I understand what the timeout value does, I was referring to the time it takes when the timeout dialog pops up, then I have to change my focus to that dialog, and press enter, and then change my focus back to wherever I was in the source. I'm sure you know how that's an incredibly distracting experience, especially when it accidentally happens as the mouse pointer drifts across a comment line or something! Of course, in my situation I had to find a 'workaround', which was to move the mouse pointer out of the source editor window! ---------------------------------------------------------------------- Martin_fr · 2012-09-28 22:36 Yes, I know it is an annoyance. The reason it is on by default is, because even though recovery works well, there is no knowing about potential later damage. So any one with a 64 bit Mac needs to be aware of the unfortunate situation. Then of course, it should be switched off, so it was no longer an annoyance...