Forum > Debugger

Debugging problem on Windows 11 ARM

<< < (2/9) > >>

Martin_fr:
Could you please add

--- Code: Text  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ----dDebuglnWinDebugEvents
Also could you apply the following patch

--- Code: Diff  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---diff --git a/components/fpdebug/fpdbgwinclasses.pas b/components/fpdebug/fpdbgwinclasses.pasindex 86e855ed0f..37b9ba35db 100644--- a/components/fpdebug/fpdbgwinclasses.pas+++ b/components/fpdebug/fpdbgwinclasses.pas@@ -784,7 +784,7 @@ function TDbgWinProcess.Continue(AProcess: TDbgProcess; AThread: TDbgThread; var   EventThread, t: TDbgThread; begin-debugln(FPDBG_WINDOWS, ['TDbgWinProcess.Continue ',SingleStep]);+debugln(FPDBG_WINDOWS, ['TDbgWinProcess.Continue ',SingleStep, ' ', DbgSTime ]);   if assigned(AThread) and not FThreadMap.HasId(AThread.ID) then begin     AThread := nil;   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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---  CallFoo(GetBar(),    GetOther(),    GetMore()  );  Then the first line, is reached several times while the others are executed.

Luc:
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

Martin_fr:
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.



--- Quote from: Luc on June 26, 2022, 11:09:25 pm ---v1 is the log saved when the "freezing" happened

--- End quote ---

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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---  EVENT for Process 26848 Thread 26740: << EXIT_THREAD_DEBUG_EVENT exitcode:0 True  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  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---procedure TDbgWinThread.Suspend; ... procedure TDbgWinThread.Resume; 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:
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:
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?
--- End quote ---

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)

--- End quote ---

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
--- End quote ---

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)
--- End quote ---
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...


Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version