FpDebug unexpected Assembler window

[440bx]

Hello,

using Lazarus v3.2 64bit, FPC v3.2.2, 64bit program being debugged.

In the attachment, on line 2214 there is an active breakpoint.  That breakpoint used to be disabled and the program was running.  While the program was running the breakpoint at that line was enabled, the act of enabling the breakpoint caused the Assembler window to, unexpectedly, open.

It seems the act of enabling the breakpoint caused FpDebug to decide to do an unnecessary remote breakin.  (guess/observation based on tracing through the code after the ret.)

[Martin_fr]

Ouch, untested side effect of the "int3" stopping.

To set the breakpoint, the debugger must internally pause the app => thus it will hit an int3....

Please bug report this.

This will probably end up a race condition...

The documented way is to inject a debugbreak in a new thread to the app.

Then the obvious would be the next int3.

But the code may call debugbreak too. And the code may start new threads too.

[440bx]

Please bug report this.

Done.  issue: 40910 link: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40910

The documented way is to inject a debugbreak in a new thread to the app.

Then the obvious would be the next int3.

But the code may call debugbreak too. And the code may start new threads too.

Instead of breaking into the process, I'd try suspending the process, placing the breakpoint then resuming the process.

Ntdll offers a very handy function to suspend a process:

Code: Pascal  [Select][+][-]

1. function NtSuspendProcess                          
2.            (
3.             { _in_ } InProcessHandle : THANDLE
4.            )
5.          : NTSTATUS; stdcall; external ntdll;
6.  
7.  

That function has been around since I can remember.  I think I've seen it in use in MS debuggers, IOW, it's probably quite safe to use and doesn't have the side effects of forcefully breaking into the process.  I've used it, it works!

Almost forgot to mention its "sister" function:

Code: Pascal  [Select][+][-]

1. function NtResumeProcess                          
2.            (
3.             { _in_ } InProcessHandle : THANDLE
4.            )
5.          : NTSTATUS; stdcall; external ntdll;
6.  
7.  

Together, they are quite convenient.

HTH.

ETA:

Added code tags.

[Martin_fr]

Changing the way how to pause a process will require massive testing.

I currently added some workaround. Though I don't know for how many setups it will work.

Basically catching and identifying the injected thread. On Win 10 it has a start-point in the kernel that can be found by name (It seems it is not exported, but user apps are not likely to start a new thread, only for injecting a int3).
Though if other Window versions use a different method then it wont work for them.
=> Check the stackif/when the asm Window is still happening.


A better fix is likely to be an extensive amount of work, and not to happen soon.

However other entry points for the thread can easily be added.