[SOLVED] Setting a breakpoint hangs program

[Wings2018]

I recently extended a program with some lines of code and are facing a problem when setting a breakpoint (at any location with in the program).

Sequence:
1. open FPC 3.2.2
2. load program
3. set breakpoint using ctrl+f8 at a line
4. push 'Run'

Outcome:
1. a 2nd black colored screen is opened (normal behavior)
2. screen stays black and program doesn't start (CPU-load doesn't change at all, so program is not running)
3. at the first screen the IDE stays open and I can use 'Run' -> 'Program reset', but then IDE gets froozen too

When I do not include a breakpoint and run from within the IDE, or start my program via the CLI, I can fill in my usual user values and the program runs in both causes without any problem.

Questions:
1. Why does the insertion of just 1 breakpoint causes the hang-up? I always worked perfectly fine
2. The program including the applied units is about 103 k lines, does that pose a problem?
3. The main program contains ~55 k lines, would it make sense to move code to new units, or will it not help?

[Martin_fr]

First of all, I don't use the FP IDE, but I may still have a few hints that may be of interest.

Afaik the FP IDE use gdb (or more to the point libgdb) to do the debugging. So if something hangs gdb, then that may hang the target app (since gdb would not start it, or not continue it, once it stopped for any reason, e.g. breakpoint).

Also, libgdb means its part of the main process, and it may therefore hang the main IDE too. Though I don't know exactly how its integrated.

If it is a gdb issue (including any issue in gdb caused by broken debug info, which FPC sometimes generates) then it may be worth testing for some of those.

1) On Win64 FPC may write some wrong addresses, which leads to incorrect placed breakpoint and crashes of the app (usually breakpoints on the last few lines of a procedure, but in theory: anywhere). That can be remedied by using an external assembler.

2) In general, ensure to compile with -O-  (no optimization whatsoever) / Also NO smart linking

3) If the FP IDE gives you the choice, then chose DWARF-2 (you can use -godwarfsets) / Do NOT use DWARF-3 or 4 with gdb.

[marcov]

(Afaik since FPC 3.2, only targets that miss multi process support still use libgdb. I verified that win32 FP 3.2.2 uses external GDB)

[Thaddy]

Yes, it uses GDB/MI and that is correct. (Starts external GDB and interfaces through MI). That is not libgdb.
I did not debug through / with fp.exe for a long time, but I can't see why that would have changed. That would be strange.

[Wings2018]

All,

An update on this topic:

By also using Copilot on potential rootcauses, I got several options where the addition of a delay at the very first line of the main-program turned out to solve my start-up problem (highly probably the crt-unit needs some time to initialize hardware from within the IDE). A delay of 50-100 ms was on the edge of a successful start-up so I applied 'delay(250)' to be sure, and that works flawlessly.

As I could not find a solution on how to get rid of the multiple breakpoints topic, I decided to stop using FPC 3.2.2 and switched over to Lazarus 4.2 / FPC 3.2.2 win64, and that environment is indeed a great improvement! Took me 1 day to learn the main functions of the IDE and was able to compile and run (even without the 'delay(250)' !). Also, setting multiple breakpoints is no topic anymore.

I'm closing this topic, thanks everybody for your feedback and hints !