Breakpoint addition or removal

[Neville]

During a debug session, and exception is caused by either adding or removing a breakpoint. Version 2.0.12

[MarkMLl]

Has it already been reported using https://bugs.freepascal.org/ ?

If not please do so, providing the overwhelmingly-important information of what OS you're running etc.

MarkMLl

[Martin_fr]

You are probably on Windows?

- Is your OS/CPU: 64 or 32 bits?
- Did you download the main IDE as 64 or 32 bits?
  Check in the Windows "Task Manager" if says "Lazarus (32 bit)"?
- Are you cross compiling to 64 or 32 bits?

Further more, when do you set the breakpoint?
- Before you run your app?
- While your app is paused in the debugger
- While your app is running in the debugger?

What exactly does the exception say?
Important, if there is a "more" button, what is the info show when pressing it?

[Martin_fr]

For anyone not following the mantis issue. https://bugs.freepascal.org/view.php?id=38602

It appears this is caused by cross debugging a 32bit project in a64 bit IDE (using the gdb based debugger)

This is fixed in trunk for 2.2 when that will be released.
But can not be merged to 2.0.x.


Under 2.0.x (and earlier) a 64bit Lazarus IDE using gdb can't debug a 32bit target.  (At least not on current Windows 10 / not verified with other/older Win / IIRC it used to work).

There are 2 options:
1) Installing a 32bit Lazarus.

2) Recommended
Using a 64bit IDE (actually 64 or 32 / does not matter) with FpDebug.
Menu: Packages > Install Packages: Select "LazDebuggerFp", install, rebuild.
Menu: Tools > Options > Debugger: Select "FpDebug"

For a feature compare: https://wiki.lazarus.freepascal.org/Debugger_Status
Also if you debug a lot into dll, or into the RTL, then fpdebug may not always get the full stack. In normal operation that should not matter.

Hope this helps.

---
EDIT:
The feature compare is based on svn trunk.

And if your 32bit apps launches 64bit exe (e.g. with TProcess or similar) then there is https://bugs.freepascal.org/view.php?id=38546

[MarkMLl]

Thanks for the update Martin. I've got a problem relating to different shared-object library behaviour in 32- and 64-bit, so knowing that is probably relevant.

MarkMLl

[Martin_fr]

Thanks for the update Martin. I've got a problem relating to different shared-object library behaviour in 32- and 64-bit, so knowing that is probably relevant.

Background to the problem with the breakpoint add/remove.

When the application is running, the IDE can not ask gdb to perform any task (that differs, when using gdb-server).
So when
- breakpoints are changed(properties)/added/removed
- the visible editor tab is changed, and blue dot info is needed for a file
- the pause button is pressed

Then the exe needs to be paused for a tiny moment. To do that the IDE calls a window API, to inject a int3.
When that happens the OS, invokes the debugger and provides an event code for this.

A 64 bit process (IDE) can execute that on a 32bit target.  But the OS sends a different event code in that case. GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.

Lazarus trunk will run an additional helper process in 32bit mode to send the signal.

FpDebug understands the different event code. So it works.

[440bx]

To do that the IDE calls a window API, to inject a int3.
<snip>
GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.

Just a thought and, I don't really know if it would work but, might be worth a try.  If instead of injecting an int 3 that neither GDB nor the app expect, _maybe_ suspending all the debuggee threads then have the IDE tell GDB to place the int 3 where desired.  Since the debuggee is suspended, that _might_ work and the int 3 will no longer be unexpected by GDB (since it is there because _it_ placed it there.)

[Martin_fr]

To do that the IDE calls a window API, to inject a int3.
<snip>
GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.

Just a thought and, I don't really know if it would work but, might be worth a try.  If instead of injecting an int 3 that neither GDB nor the app expect, _maybe_ suspending all the debuggee threads then have the IDE tell GDB to place the int 3 where desired.  Since the debuggee is suspended, that _might_ work and the int 3 will no longer be unexpected by GDB (since it is there because _it_ placed it there.)

Suspending the threads is not going to help.  While the app is running, gdb is in the "-exec-continue" command. And gdb will not accept any other commands until that finishes. So nothing can be send to gdb.

If you run gdb on a comand-line, you do ctrl-c and gdb will interrupt the app. But that does not work from the IDE. It did last on Win-95. (IIRC)
Gdb has an asynchronous command mode, where you could send the "interrupt" command (then gdb injects the int3). But that mode does only work with gdbserver, and some few special targets. Not on Windows.
You have to sent sent that int3.

Also, we have a working solution. The SVN 2.1 trunk IDE can run in 64bit, and use gdb to debug a 32bit target.

Further gdb will become more and more the option for remote debugging, embedded, and similar. Native (Win/Linux) will move to FpDebug.

-------
I just retested with gdb 9.2 => it still does not understand that code.

Gdb 10.1 introduces new errors when evaluating watches (watches that used to work, like "shortstring"). So I have not tested it. Would not help anyway.
There are rumours on stack overflow, that gdb 10 may have it fixed. But does not help, if it crashes on watches

[440bx]

Martin, thank you for explaining the issues.  Appreciate it.

[MarkMLl]

Thanks for the detail Martin. Interesting and thought-provoking from the POV of system software design.

MarkMLl

[Martin_fr]

If you want to dig in https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-waitfordebugevent
This is where the debugger waits for the OS to inform it. It links all the events that the debugger can get.
You can find it in fpdebug, if you want to watch it in action.