Forum > Debugger

[SOLVED]How did I manage to screw up debugging in lazarus

(1/7) > >>

Somehow, in the last couple of days, I managed to f*ck up my debugger in laz; i.e.: When I try to debug even a simple program, I set a breakpoint at the first executable line and click Play; it compiles and runs (I think), that is, it just leaves me there, with the breakpoint still red(not grey, like when debugging) and I can't do anything, apart from clicking the red Stop button?!? which then kills the debugging process altogether... Funny thing, though, the program runs fine outside the debugger  %) So the last few days I've been debugging with "Writeln" and Logfiles; It's suboptimal, to say the least.... >:(
I need a little help on this... Oh, I do have some fairly complex units of code I'm working on, e.g.: a "Service-framework" and a "Plugin-framework" and it's a nuiscence without proper debugging  :o
FPC 3.2.2 & Laz 2.2.6, both used to be stable releases...
Regards Benny

I’ve had some problems with break points not going away.
I don’t know if this will help but I delete all the breakpoints when I have problems with them

The old questions arise:
What kind of system you are using (Linux, Win,...?
What debugger have you configured (or misconfigured) (GDB or fpDebug or ?)
Have you choiced a type for debugginginfos ?
Are you executing with a debugger ?

@af0815: As stated above are the versions of stable fpc & laz -> 3.2.2 & 2.2.6
My OS is fully updated PCLinuxOS with QT5 and I'm using FpDebug with dwarf3 for debugging, along with a debugger friendly debug.xml file and an optimized release.xml files... for their respective uses.
Would it perhaps help to rebuild lazarus? As it stands, its very standard, no extra added components etc.
It's sad, 'cause I kinda like the FpDebugger over GDB, but alas, switching over to GDB didn't help at all, so switched back to FpDebug.
It's not a deadlock, I've checked and I can kill it with a click on the red stop button. The program runs as it should outside lazarus & FpDebug or GDB?!?
Regards Benny

First of all, make sure your project does not have old or duplicate ppu or o files.

If you have include path (maybe mixed with packages...). So also check in any packages that you have.
Ideally remove all ppu files, and rebuild.
If you use external debug info, also remove the dbg file.

Then ensure, that there are no symlinks into your project/packages. I am not sure if it affects fpdebug...., or was only with gdb. But if you have symlinks, and your IDE knows a file as "/home/you/project_foo/unit.pas", yet the compiler (and also debugger) know it as "/home/you/project_foo_alias/unit.pas" then that can cause all sort of issues.

You say "only stop works" => what about the pause button? That should work too, it should pause and display the asm window.

When you run your app, does the editor show small blue dots in the gutter (where it also shows the breakpoints) in any of your units? (for at least some of the functions?)

Do you use "type TFoo = object" ? (old style)
or generics?

--- Quote ---t compiles and runs (I think), that is, it just leaves me there, with the breakpoint still red(not grey, like when debugging)
--- End quote ---
Breakpoints shouldn't be grey, when debugging...
(breakpoints can be green, if you disable them)

It being "red" is good and correct. The important question is what symbol is show on the breakpoint.

? => this should only be on the breakpoint when your debugger is not running
X => this indicates the breakpoint could not be set
V (checkmark) => this means the breakpoint was activated for the debug session (This is what it should be, while debugging)
|| (pause symbol) => Not activated, the debugger did not find the unit in your app (usually if the code may be part of a library, not yet loaded)


[0] Message Index

[#] Next page

Go to full version