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

[cdbc]

Hi
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 
FPC 3.2.2 & Laz 2.2.6, both used to be stable releases...
Regards Benny

[Joanna]

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

[af0815]

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 ?

[cdbc]

Hi
@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

[Martin_fr]

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?

t compiles and runs (I think), that is, it just leaves me there, with the breakpoint still red(not grey, like when debugging)

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)

[cdbc]

Hi
first off, see attachment...
Regards Benny

[cdbc]

Hi
@martin_fr:
Second off...
- no objects, I have classes and corba interfaces
- no generics, don't know how to use them yet 
- yes, there are blue dots in all units; for testing, I've removed threading,
  locking, shared memory and loading of plugin-libraries...
- I've vreated one class to hold: a data-container(bom), reader & writer-
  classesp(backend) for providing data, the test-object itself(soon to be a
  plugin lib) for transferring data to new location, also a class, a "Print"
  procedure to write data to console and a "Transfer" procedure to transfer
  data...
- when I compile it (with or without debug info) and run it from a console, it
  works just fine, I just cannot debug the darn thing!
- when I click "Pause", I get the asm-view seen in attachment, alas, I don't
  read asm'sk  :'(
Hope it all makes sense to you 
Help, please
Regards Benny

[Martin_fr]

Ok, that looks all correct.

1) Have you tried a breakpoint on a different line (not an a "begin" line).
It shouldn't matter, but ...

2) If using optimization level 1 => try level 0  -O-

FPC 3.2.2 & Laz 2.2.6,

Oh, important 3.2.2 => that has a nasty bug, which at least on Windows 64 bit has screwed the debugger before. If you compile your IDE, compile with maximum -O1

-O2 and may break the debugger.
On Linux, well it hasn't been reproduced before, but ...

[cdbc]

Hi
1) The breakpoint is on "begin"-line, because it's the only line where, it turns
   grey, as if it would start debugging, when I step into(F7), it all goes byebye.
2) Just tried with optimization = 0; => no change.
3) Do you think it would help to recompile the IDE with optimization 0 or 1???
4) I'd hate to have to recompile FPC, as I normally ask my distro-people, to
   compile and package fpc & lazarus for me, then I have them in a couple of
   hours and part of the distro Nice with a rolling release and people in the
   know behind it  PCLinuxOS-kde/QT5 (libc 2.34)
Thanks for your help so far, anything else I can do? 
Regards Benny

[Martin_fr]

1) The breakpoint is on "begin"-line, because it's the only line where, it turns
   grey, as if it would start debugging, when I step into(F7), it all goes byebye.

I am still not sure about "turning grey" => breakpoints don't get grey.
Though, the line background color may turn grey, but that is if the breakpoint is hit => so then the debugger would have stopped at the breakpoint.

When that happens => does the stackwindow (open it before) show any form of life? I.e., does it fill up with a stack trace for at least a very brief moment?
Open the history Window (debug windows)=> does it have an entry?

I would assume that you at some point deleted and reset the breakpoint? Otherwise, does it have "break" enabled, and "auto continue" not set?
(Because a breakpoint can do other things than just break)

2) Just tried with optimization = 0; => no change.
3) Do you think it would help to recompile the IDE with optimization 0 or 1???

On Windows => definitively.
On Linux => I haven't seen problems with the IDE compiled -O2 / but it is possible

There is a bug in fpc 3.2.2, where it wrongly translates some parts of the IDE, if the IDE is compiled with -O2 (or higher).

4) I'd hate to have to recompile FPC, as I normally ask my distro-people, to

No need. (Or not that I know of)

anything else I can do? 

Run the IDE from a terminal, so you can see the IDE stdout. Maybe the debugger prints out some error or warning.

Run lazarus as
 lazarus.exe   --debug-log=FILE   --log-enable=DBG_STATE,DBG_DATA_MONITORS,DBG_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS

and attach the file.
NOTE: the file may contain unit names, and names from your sources (variables, functions, types...)

[cdbc]

Hi
first breakpoint...

[cdbc]

Hi
second callstack...

[Martin_fr]

But the callstack picture shows your app is paused?

- There is a callstack
- The green run ("play/triangle") button is active
- the "pause" button is not active.

For all I can see your app is paused at the callstack?

Did I misread something in your earlier posts?
I thought you said the debugger does not break at the breakpoint?

[cdbc]

No you understand it right, as I said, THIS "begin"-line is the only place where the debugger breaks/pauses, one more step(F7) and it's all byebye...
Here is an end-message from running in a console...:

Code: Text  [Select][+][-]

1. LAZARUS END - cleaning up ...
2. FreeFormEditor: FormEditor1=TFormEditor
3. Hint: (lazarus) [TMainIDE.Destroy] B  -> inherited Destroy... TMainIDE
4. Hint: (lazarus) [TMainIDE.Destroy] END
5. Heap dump by heaptrc unit of /home/bc/.lazarus/bin/lazarus
6. 12879891 memory blocks allocated : 2023413665/2049940392
7. 12879883 memory blocks freed     : 2023412897/2049939624
8. 8 unfreed memory blocks : 768
9. True heap size : 917504
10. True free heap : 917504
11. Should be : 915200
12. Call trace for block $00007F9C80F12240 size 96
13.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
14.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
15.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
16. Call trace for block $00007F9C80F12100 size 96
17.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
18.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
19.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
20. Call trace for block $00007F9C815CB240 size 96
21.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
22.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
23.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
24. Call trace for block $00007F9C815CB100 size 96
25.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
26.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
27.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
28. Call trace for block $00007F9C8157B240 size 96
29.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
30.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
31.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
32. Call trace for block $00007F9C8157B100 size 96
33.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
34.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
35.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
36. Call trace for block $00007F9C80C42240 size 96
37.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
38.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
39.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
40. Call trace for block $00007F9C80C42100 size 96
41.   $00000000014DC816  DOEXECUTE,  line 4095 of fpdbgdwarfdataclasses.pas
42.   $0000000001512178  EXECUTEINTHREAD,  line 580 of fpdbgutil.pp
43.   $0000000001513AA0  EXECUTE,  line 860 of fpdbgutil.pp
44.  
45. [bc@hp test_app]$

Looks kind of interresting...

[Martin_fr]

The leaks could mean that the debugger was not cleanly exited (like when "reset debugger" is executed (the don't have to happen).
They could have other causes, but don't directly point to stepping and breakpoints. (and line number mapping gets loaded, as you get the blue dots)


Please start the IDE with the logfile setting from my previous post.

- set the breakpoint on the begin line
- start debugger with run, so it will pause at that begin line
- when paused at the begin line: click the gutter to set a breakpoint on the line TWO below that (take note if it gets a checkbox, or other symbol)
- press F8 as if to single step
- Stop
- Reset debugger
- Exit IDE

send the logfile please.

---
For this test, disable "external debug info" (if you do use that). So the debug info will be part of an oversized executable.