Recent

Author Topic: Debugging problem on Windows 11 ARM  (Read 2261 times)

Luc

  • Jr. Member
  • **
  • Posts: 57
Debugging problem on Windows 11 ARM
« on: June 24, 2022, 06:49:51 pm »
Hi,

I have some trouble using fpDebug on Windows 11 ARM + Parallel VM: The debugger stops at the first breakpoint found in the program flow, no problem here. But quite often (not every time) when I press F7 or F8 or F9 the IDE doesn't step and doesn't give back the execution flow to the program being debugged.

Everything is fine under Win8 or Win10 x64 + Parallel VM.

Thanks
Luc
Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #1 on: June 24, 2022, 08:35:11 pm »
Not quite clear what you do:

- Debugging an arm/avr target, with the avr-embedded FpDebug?
- Debugging an x84-64 program in the VM? (And presumingly the IDE also running in the VM?)

If the latter, then try running:
Code: Text  [Select][+][-]
  1.     lazarus.exe --debug-log=c:\laz-log.txt --debug-enable=DBG_VERBOSE,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,FPDBG_DWARF_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_STATE,DBG_EVENTS,DBG_THREAD_AND_FRAME,DBG_ERRORS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_THREADS,FPDBG_QUEUE,FPDEBUG_THREAD_CHECK,FPDBG_WINDOWS    

And get the output attached. It may contain names/symbols from your app. If that is an issue, then remove that part first.


Also if you can: try running Lazarus 2.3.


Very important
If you did rebuild your IDE, make sure you used max -O-1  (or FPC 3.2.3 or 3.3.1)

If you used -O2 or above to build the IDE, there is a bug in fpc 3.2.2, and fpdebug will misbehave.

Luc

  • Jr. Member
  • **
  • Posts: 57
Re: Debugging problem on Windows 11 ARM
« Reply #2 on: June 25, 2022, 04:06:06 pm »
Thanks Martin,

Sorry to not being clear. I am

Quote
Debugging an x84-64 program in the VM? (And presumingly the IDE also running in the VM?)

I enclosed my current settings (removing the used libs as it should not be relevant here). The IDE was rebuilt with -O1. I did some more tests with a simple project and I don't have any problem with it.

The one I have problems with is far more complex and uses many Forms or Frames.

The laz-log - NQ.txt doesn't seem to bring some light but I also enclose a screenshot of the assembler windows when the debugger hangs (The IDE is still responding but I cannot go back to the program being debugged nor stepping the code).

As a side note, I also found that you still can select "use external debug symbols file" when fpDebug is selected as the default debugger. AFAIK, this option should be disabled in the IDE with fpDebug?

Please let me know if there is something else I can do to solde this breakpoint problem.
« Last Edit: June 25, 2022, 04:13:39 pm by Luc »
Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #3 on: June 25, 2022, 04:59:59 pm »
Quote
As a side note, I also found that you still can select "use external debug symbols file" when fpDebug is selected as the default debugger. AFAIK, this option should be disabled in the IDE with fpDebug?
FpDebug does support this. (at least in 2.3 / not sure when it was added). But it has no benefit. (Unless someone ships their releases with -O-1 -Criot -gh -Sa  => which is what a debug build should normally have... IMHO)


Ok, the log framework appears to have some bug. The debug-enable does not seem to work.

Can you recompile and add the following options in the "configure build lazarus"
Code: Text  [Select][+][-]
  1. -dDBG_VERBOSE
  2. -dDBG_STATE
  3. -dDBG_DATA_MONITORS
  4. -dDBGMI_QUEUE_DEBUG
  5. -dFPDBG_DWARF_ERRORS
  6. -dDBG_VERBOSE
  7. -dDBG_WARNINGS
  8. -dDBG_STATE
  9. -dDBG_EVENTS
  10. -dDBG_THREAD_AND_FRAME
  11. -dDBG_ERRORS
  12. -dDBG_FPDEBUG_VERBOSE
  13. -dFPDBG_BREAKPOINT_ERRORS
  14. -dFPDBG_BREAKPOINTS
  15. -dFPDBG_COMMANDS
  16. -dFPDBG_THREADS
  17. -dFPDBG_QUEUE
  18. -dFPDEBUG_THREAD_CHECK
  19. -dFPDBG_WINDOWS    
  20.  

And then just
Code: Text  [Select][+][-]
  1.  lazarus.exe --debug-log=c:\laz-log.txt

Luc

  • Jr. Member
  • **
  • Posts: 57
Re: Debugging problem on Windows 11 ARM
« Reply #4 on: June 25, 2022, 06:53:24 pm »
Much better now I think  :)

Here is the log file. I was able to step over F8 several times then I tried F9 and it hanged again. It appears to have "access is denied" messages in the log file but I don't know if it is relevant here.
Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #5 on: June 25, 2022, 09:44:05 pm »
Could you please add
Code: Text  [Select][+][-]
  1. -dDebuglnWinDebugEvents

Also could you apply the following patch
Code: Diff  [Select][+][-]
  1. diff --git a/components/fpdebug/fpdbgwinclasses.pas b/components/fpdebug/fpdbgwinclasses.pas
  2. index 86e855ed0f..37b9ba35db 100644
  3. --- a/components/fpdebug/fpdbgwinclasses.pas
  4. +++ b/components/fpdebug/fpdbgwinclasses.pas
  5. @@ -784,7 +784,7 @@ function TDbgWinProcess.Continue(AProcess: TDbgProcess; AThread: TDbgThread;
  6.  var
  7.    EventThread, t: TDbgThread;
  8.  begin
  9. -debugln(FPDBG_WINDOWS, ['TDbgWinProcess.Continue ',SingleStep]);
  10. +debugln(FPDBG_WINDOWS, ['TDbgWinProcess.Continue ',SingleStep, ' ', DbgSTime ]);
  11.    if assigned(AThread) and not FThreadMap.HasId(AThread.ID) then begin
  12.      AThread := nil;
  13.    end;
This will give me some time-stamps.

If you can't get the patch in, then when you get the issue, wait at least half a minute, before pressing stop.
And also, if you can, copy the log-file before pressing stop, though the full file will also be needed, since when the copy is taken not all content may have been written (not flushed to disk).


Further, if possible
- close the locals dialog
- clear (or disable) the watches dialog
- important: open the "debug history" and disable it (power button off)
Though, its not likely to make a difference. The log does not show anything that would point towards watch/locals.





What I can see...

There are several threads. But they may be from the OS, or other dll.

- You did hit a breakpoint, and then several F8 (around line 800)
- Then an F8 did step out, to line 415
- Next a step to line 416
- Then run with F9  (at least that is what it looks like)
  -> which eventually stopped at the same breakpoint again
- Again F9 -> this time stopping at a different breakpoint
- Again F9
  -> and then something goes wrong
... It looks that at some point, during this you did press "stop" ?

From what it looks like, some thread in your app did exit.
I can't tell exactly if that was the thread you were debugging, or one of the other threads (i.e. some thread inserted by the OS, which would mean that thread may well have been ok to exit).

It does look like it may be one of those other threads. (The above "-dDebuglnWinDebugEvents" hopefully will tell).
If so, that is probably a rare event to happen (i.e. the thread-exit happening exactly at a very specific moment in what fpdebug does).

Then again, my guess is that all the "Access is denied." are threads that did finish => and if that many threads go down, something else may have happened.






Note: Several stops at a breakpoint
- well, either you did actually run all the way, and just came back
- Or...
  If a single command wraps several lines
Code: Pascal  [Select][+][-]
  1.   CallFoo(GetBar(),
  2.     GetOther(),
  3.     GetMore()
  4.   );
  Then the first line, is reached several times while the others are executed.

Luc

  • Jr. Member
  • **
  • Posts: 57
Re: Debugging problem on Windows 11 ARM
« Reply #6 on: June 26, 2022, 11:09:25 pm »
Thanks Martin for taking the time to investigate this issue.

I followed up all the instructions but the problem is still here.

To simplify the debug process I added a breakpoint in the main form which is triggered by a simple click in the main thread context.

I enclosed 3 files:
v1 is the log saved when the "freezing" happened after 2 x F9 I think (sometime the first F9 freezes the debugger)
v2 is the log saved after stopping the execution. I waited at least 1 min but nothing was added to the log
v3 is the log saved after closing the IDE

There are 5 or 6 threads running at program start (depending on the context). I can try to disable them if you think the problem could be related.

I don't have any problem debugging on OSX + i7 + VM + Win 8.1 + Lazarus x64->x32
Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #7 on: June 27, 2022, 11:12:43 am »
Still very strange.

According to the messages that Windows sends to the debugger, the debugged app exited without any error (errorcode = 0).
This happens within 1 second from when you tried to continue with F9.


v1 is the log saved when the "freezing" happened

About "freezing", from the log it looks like the debugger stopped "normally" (well, ignoring that it shouldn't stop...).
That is, it should behave as if the app just exited.

I take it, that you probably disabled "show message on stop" from "tools > options > debugger > general".
So you don't get the message box "Execution stopped".
==> You should however see that the red stop-button gets disabled (greyed), and the green-start button enabled again?

So if you say "freeze" what exactly does that describe?
- What are the states of the debugger tool buttons?
- What does the caption of the IDE title-bar say (does it still say "debugging")?
- If, it is stopped, can it be started again with F9 or Run?
  (Note, if you press F8 while the debugger is stopped, then the debugger will hang)


Depending on whether the debugger "stops" or "freezes", there are one or two issues.
- Issue 1: your app terminates, when it certainly should not
- Issue 2: the debugger hangs




About the "your app terminates".

This could be some issue with Windows11 or your VM.

It could be Windows Defender too.
Under Windows-10 there is "Windows security" > "Virus and thread protection" on that page "manage settings" => "virus and thread protection settings":
A lot of on/off switches, and at the bottom of the page "Exclusions" / "Add or remove exclusions"
Add both, the IDE, and the debugged app.


There is a bit of a "chicken and egg" issue with all the "access denied" in the logfile.
I can't tell, if they (all/some of them) are a consequence of your app terminating or if some of them are causing (indirectly, via fpdebug) your app to terminate.
Though in the latter case, I would not expect "error code = 0"

Code: Text  [Select][+][-]
  1.   EVENT for Process 26848 Thread 26740: << EXIT_THREAD_DEBUG_EVENT exitcode:0 True
  2.   EVENT for Process 26848 Thread 13200: << EXIT_PROCESS_DEBUG_EVENT exitcode:0 True

There is one test you could do.
   components\fpdebug\fpdbgwinclasses.pas
   line 1600
Code: Pascal  [Select][+][-]
  1. procedure TDbgWinThread.Suspend;
  2.  
  3. ...
  4.  
  5. procedure TDbgWinThread.Resume;
  6.  
In both procedures insert an "exit;" as very first statement. So both functions will exit without doing anything at all.

Then FpDebug will no longer try to disable a thread that has exited. In case this somehow causes more other threads to exit.
It is possible that some of the threads are valid to exit at those time. This could be threads the OS added, and they are expected to terminate at some time.








F8 while the debugger is stopped
FpDebug can only be started with F9/Run.
However the IDE does not obey that, and will send an F8 (in order to start debugging / as gdb does accept this).
In that case, FpDebug does not start, but the IDE believe it is running => only "reset debugger" will work.



Btw, while not ideal, but you can still use gdb and at least be able to debug (unless gdb has the same issue).
Tools > Options > Debugger Backend



Also can you please confirm: Your IDE is 64bit and your are cross debugging to 32bit? (Which should work)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #8 on: June 27, 2022, 12:36:28 pm »
One more thing, I can see there are libraries unloaded shortly before the breakpoint. However, I can't see their names.

So to make sure they are not related, can you open the debugger event log (and ensure in the Tools > Options ...) that library events are shown (should be on by default).

Then just check the last few entries before the issue arises.

Luc

  • Jr. Member
  • **
  • Posts: 57
Re: Debugging problem on Windows 11 ARM
« Reply #9 on: June 27, 2022, 02:44:46 pm »
Indeed, this is strange.
 
Quote
I take it, that you probably disabled "show message on stop" from "tools > options > debugger > general".
So you don't get the message box "Execution stopped".
==> You should however see that the red stop-button gets disabled (greyed), and the green-start button enabled again?

Yes, the message box "Execution stopped" is disabled but the program being debugged never exits by itself and the IDE is always showing "debugging". You can see it in the screenshoot. The Task Manager shows the debugged exe as "Not responding" (PID 5912), the IDE "Debugging" and nothing happen when I hit F9 or any other debugging key. The assembler window shows the last breakpoint hit but all the assembler lines disappear if I resize the assembler windows like if it were not available anymore.

Quote
So if you say "freeze" what exactly does that describe?
- A - What are the states of the debugger tool buttons?
- B - What does the caption of the IDE title-bar say (does it still say "debugging")?
- C - If, it is stopped, can it be started again with F9 or Run?
  (Note, if you press F8 while the debugger is stopped, then the debugger will hang)

A and B: Please have a look at the screenshot
C: No, unable to run the program again

Quote
Depending on whether the debugger "stops" or "freezes", there are one or two issues.
- Issue 1: your app terminates, when it certainly should not
- Issue 2: the debugger hangs

Issue 1: No the debugged app doesn't exit. It is still running but kind of "captured" by the debugger
Issue 2: It seems so but the IDE is still fully responding.

Quote
Also can you please confirm: Your IDE is 64bit and your are cross debugging to 32bit? (Which should work)
Yes this is the case.

I tried to follow your instructions to the best, disabling all the Win 11 system security for lazarus.exe, changing the IDE debugger options, activating all the options in debug_log, applying the "exit" statements (Suspend, Resume) and so on but still no luck  :(

You will find another log file which hopefully could give you some more information.

At the end, I switched to gdb and it seems to work fine so far.
Let me know if I can help solving this problem with fpDebug, may be a simple one but hard to catch...


Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #10 on: June 27, 2022, 02:57:44 pm »
Ouch, when I compared the timestamps
814140
814401

I somehow -in my mind  - swapped some digits around, and saw 1 sec difference.... My bad.
So then, all the "access denied" is fine. That is when you stop the app. And expected.

Let's look again.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #11 on: June 27, 2022, 06:17:33 pm »
OK, so indeed the app is just kept suspended....

I have 2 ideas. I added a lot of debug output.

Here the patch (or attached the complete file, based on 2.2)
Code: Diff  [Select][+][-]
  1. diff --git a/components/fpdebug/fpdbgwinclasses.pas b/components/fpdebug/fpdbgwinclasses.pas
  2. index 9d5094a167..9b3b757500 100644
  3. --- a/components/fpdebug/fpdbgwinclasses.pas
  4. +++ b/components/fpdebug/fpdbgwinclasses.pas
  5. @@ -722,6 +722,11 @@ class function TDbgWinProcess.isSupported(ATargetInfo: TTargetDescriptor
  6.              (ATargetInfo.machineType in [mt386, mtX86_64]);
  7.  end;
  8.  
  9. +function dbgsThread(AThread: TDbgThread): string;
  10. +begin
  11. +  if AThread = nil then result := 'nil' else Result := IntToStr(AThread.ID);
  12. +end;
  13. +
  14.  function TDbgWinProcess.Continue(AProcess: TDbgProcess; AThread: TDbgThread;
  15.    SingleStep: boolean): boolean;
  16.  
  17. @@ -740,7 +745,7 @@ function TDbgWinProcess.Continue(AProcess: TDbgProcess; AThread: TDbgThread;
  18.  var
  19.    EventThread, t: TDbgThread;
  20.  begin
  21. -debugln(FPDBG_WINDOWS, ['TDbgWinProcess.Continue ',SingleStep]);
  22. +debugln(FPDBG_WINDOWS, ['TDbgWinProcess.Continue ',SingleStep, ' ',DbgSTime, ' thread=',dbgsThread(AThread), ' event-tid=', MDebugEvent.dwThreadId]);
  23.    if assigned(AThread) and not FThreadMap.HasId(AThread.ID) then begin
  24.      AThread := nil;
  25.    end;
  26. @@ -804,6 +809,7 @@ function TDbgWinProcess.Continue(AProcess: TDbgProcess; AThread: TDbgThread;
  27.      if SingleStep then
  28.        TDbgWinThread(AThread).SetSingleStep;
  29.    end;
  30. +debugln('go before continue');
  31.    AProcess.ThreadsBeforeContinue;
  32.  if AThread<>nil then debugln(FPDBG_WINDOWS, ['## ath.iss ',AThread.NextIsSingleStep]);
  33.  
  34. @@ -811,13 +817,18 @@ function TDbgWinProcess.Continue(AProcess: TDbgProcess; AThread: TDbgThread;
  35.      case MDebugEvent.Exception.ExceptionRecord.ExceptionCode of
  36.       EXCEPTION_BREAKPOINT, STATUS_WX86_BREAKPOINT,
  37.       EXCEPTION_SINGLE_STEP, STATUS_WX86_SINGLE_STEP: begin
  38. +debugln(['GOING TO RUN: DBG_CONTINUE ',MDebugEvent.dwThreadId]);
  39.         result := Windows.ContinueDebugEvent(MDebugEvent.dwProcessId, MDebugEvent.dwThreadId, DBG_CONTINUE);
  40.       end
  41. -    else
  42. -      result := Windows.ContinueDebugEvent(MDebugEvent.dwProcessId, MDebugEvent.dwThreadId, DBG_EXCEPTION_NOT_HANDLED);
  43. +     else begin
  44. +debugln(['GOING TO RUN: DBG_EXCEPTION_NOT_HANDLED ',MDebugEvent.dwThreadId]);
  45. +        result := Windows.ContinueDebugEvent(MDebugEvent.dwProcessId, MDebugEvent.dwThreadId, DBG_EXCEPTION_NOT_HANDLED);
  46. +    end;
  47.      end
  48. -  else
  49. +  else begin
  50. +debugln(['GOING TO RUN: DBG_CONTINUE ',MDebugEvent.dwThreadId]);
  51.      result := Windows.ContinueDebugEvent(MDebugEvent.dwProcessId, MDebugEvent.dwThreadId, DBG_CONTINUE);
  52. +  end;
  53.    DebugLn((FPDBG_WINDOWS or DBG_WARNINGS) and (not Result), 'ContinueDebugEvent failed: %d', [Windows.GetLastError]);
  54.    result := true;
  55.    MDebugEvent.dwProcessId := 0; // Flag as running // for assert in ReadThreadState
  56. @@ -1562,6 +1573,7 @@ procedure TDbgWinThread.Suspend;
  57.  var
  58.    r: DWORD;
  59.  begin
  60. +debugln(['About to suspend ', id, ' already=', FIsSuspended, ' skip break=',FIsSkippingBreakPoint]);
  61.    if FIsSuspended then
  62.      exit;
  63.    r := SuspendThread(Handle);
  64. @@ -1586,6 +1598,7 @@ procedure TDbgWinThread.Resume;
  65.  begin
  66.    if not FIsSuspended then
  67.      exit;
  68. +debugln(['About to Resume', id]);
  69.    r := ResumeThread(Handle);
  70.    FIsSuspended := not(r <> DWORD(-1));
  71.    debugln(DBG_WARNINGS and (r = DWORD(-1)), 'Failed to resume Thread %d (handle: %d). Error: %s', [Id, Handle, GetLastErrorText]);
  72. @@ -1609,11 +1622,17 @@ procedure TDbgWinThread.SetSingleStep;
  73.      if not ReadThreadState then
  74.        exit;
  75.    {$ifdef cpux86_64}
  76. -  if (TDbgWinProcess(Process).FBitness = b32) then
  77. +  if (TDbgWinProcess(Process).FBitness = b32) then begin
  78. +debugln(['Settig single step flag ', id, '  current = ', FCurrentContext^.WOW.EFlags or FLAG_TRACE_BIT]);
  79.      FCurrentContext^.WOW.EFlags := FCurrentContext^.WOW.EFlags or FLAG_TRACE_BIT // TODO WOW_FLAG....
  80. -  else
  81. +  end
  82. +  else begin
  83.    {$endif}
  84. +debugln(['Settig single step flag ', id, '  current = ', FCurrentContext^.def.EFlags or FLAG_TRACE_BIT]);
  85.      FCurrentContext^.def.EFlags := FCurrentContext^.def.EFlags or FLAG_TRACE_BIT;
  86. +  {$ifdef cpux86_64}
  87. +  end;
  88. +  {$endif}
  89.    FThreadContextChanged:=true;
  90.  end;
  91.  
  92. @@ -1681,8 +1700,9 @@ function TDbgWinThread.DetectHardwareWatchpoint: Pointer;
  93.  
  94.  procedure TDbgWinThread.BeforeContinue;
  95.  begin
  96. +debugln(['TDbgWinThread.BeforeContinue ', id, ' / ',FThreadContextChanged, '  susp=',FIsSuspended]);
  97.    if ID = MDebugEvent.dwThreadId then begin
  98. -    inherited;
  99. +    inherited;  ///////////////////////////// MOVE this up, outside the "IF"
  100.  
  101.      {$ifdef cpux86_64}
  102.      if (TDbgWinProcess(Process).FBitness = b32) then begin
  103.  




Once you reproduced the error, and have a log for it, find the line
Code: Text  [Select][+][-]
  1.    inherited;  ///////////////////////////// MOVE this up, outside the "IF"
And move it to the begin of the procedure, so it is unconditionally executed (that is actually already done in git main, but apparently wasn't merged.

And depending, on if that helps or not, you could also follow my earlier suggestion:
(if either of my 2 ideas is correct, this should make the issue go away...)
Quote
   components\fpdebug\fpdbgwinclasses.pas
   line 1600
Code: Text  [Select][+][-]
  1.     procedure TDbgWinThread.Suspend;
  2.      
  3.     ...
  4.      
  5.     procedure TDbgWinThread.Resume;
  6.  
     
In both procedures insert an "exit;" as very first statement. So both functions will exit without doing anything at all.




A bit of background.
So the process is not started again. Well it is "started/continued", but it then does not execute a single asm instruction. So it might be started suspended.
And that is where I can think of 2 ways this could happen.

FpDebug suspends some of the threads, while it has to temporarily remove the breakpoint. If it wouldn't suspend the other threads, they could run that code, and would never hit the (temp removed) breakpoint.

1) Maybe FpDebug somehow suspends all threads - the new log will hopefully tell me.

2) When a breakpoint is hit, it's possible the OS creates a temporary thread. Then maybe if that is suspended (depending on some timing), it will hold the main thread too....
Actually, I don't see that on my Windows 10....
But I did see threads starting and stopping in your log - they may of course be something else entirely.

On that note, could you open the "thread window" and when it hangs provide a snapshot?
The log doesn't have the names of the procedures (will be somewhere in the kernel), and the thread window may show those names.




Thanks for helping.

Luc

  • Jr. Member
  • **
  • Posts: 57
Re: Debugging problem on Windows 11 ARM
« Reply #12 on: June 27, 2022, 06:37:18 pm »
Thanks Martin,
I will have a look tomorrow
Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Luc

  • Jr. Member
  • **
  • Posts: 57
Re: Debugging problem on Windows 11 ARM
« Reply #13 on: June 28, 2022, 09:27:04 am »
Hi Martin,

Problem has gone away :)

Not really as this is done by bypassing some procedures but I applied all the patches an it doesn't hang anymore.

A: I started by replacing fpdbgwinclasses.pas by the one you provided, recompiling the fpDebug package and rebuilding the IDE
Result : no change, debugger hangs

B: I moved the "inherited" on top of IF statement and rebuilt fpDebug + IDE
Result: no change, debugger hangs

C: I added Exit; on Supend and Resume procedures and rebuilt fpDebug + IDE
Result: Everything is fine, no more "hang" 

I guess you found the code causing the issue.
I can revert back to step B or A to help find the problematic code if you need so.   
Win 11 ARM (Running in Parallel VM - Mac OSX) - Lazarus 2.2.2 - i386-win32/win64

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 8095
  • Debugger - SynEdit - and more
    • wiki
Re: Debugging problem on Windows 11 ARM
« Reply #14 on: June 28, 2022, 01:31:37 pm »
A: I started by replacing fpdbgwinclasses.pas by the one you provided, recompiling the fpDebug package and rebuilding the IDE
Result : no change, debugger hangs

Expected. But could I have the logs for that run please?

And could I have a screenshot of the "threads window" while the debugger hangs?




Quote
C: I added Exit; on Supend and Resume procedures and rebuilt fpDebug + IDE
Result: Everything is fine, no more "hang" 
Ok, at least something to go on.


If you want to use FpDebug, you can use it with those 2 "exit" in place. It should be stable.

The only difference will be:
- If you have more than one thread.
- If at least 2 of them run the same code (i.e. Both of them run through the procedure "DoSomeStuff"
- You have a breakpoint in "DoSomeStuff"
- One thread stopped at that breakpoint

Now you continue (step or run) => the one thread must go over the breakpoint. For this the debugger needs to temporarily remove that breakpoint.

If the other thread reaches the place of that breakpoint, just in that tiny moment, then the other thread will pass the breakpoint without entering pause.

Example, if you have code like
Code: Pascal  [Select][+][-]
  1. for i := 0 to 9999999999 do begin
  2.   x := data[i];
  3.   if x = val then
  4.     CallFoo;  // breakpoint here
  5. end;

And you have several threads running that loop at the same time (each with its own "data"). Then one (or more) of the threads could enter "CallFoo" without stopping at the breakpoint.

 

TinyPortal © 2005-2018