Debugger freezes the PC

[simsee]

With the latest versions of Lazarus, the debugger freezes the PC, forcing me to shut down, when encountering certain run-time errors (typically access violations). This didn't happen in the past with the same application. I've attached the debugger configuration of project.

How can I fix this?

Thanks in advance.

[Martin_fr]

By the looks of the image, this is on Windows?

Windows 10 or 11? 64 bit?

An issue like this is known for gtk, but for Windows I haven't seen that before your post...

I am assuming that in menu:
   Tools > Options > Debugger > Debugger Backend
On the top of the options it says "FpDebug [FpDebug internal Dwarf debugger]"?

Have you tried to switch this to "Gdb [GNU debugger]" ?


Do you get any info before the freeze? E.g. maybe a stackframe? or Some info in a popup from the debugger?
So you would know in which function this happens?

What happens if you run the app outside the IDE (without Debugger)? It should still crash, but does the PC freeze?


Actually, I have seen Windows "semi freeze" (i.e. hanging for over a minute). But that would happen with and without debugger.

If an app uses certain resources (handles, GDI objects) in a truly excessive manner, it can get Windows to have an issue.
IIRC (and really not sure / long time ago), the app created over 1000 panels, and then did some resizes and what not....

So, if your app leaks any of that.
There is a resource monitor, in SysInternals (but I need to google what it was named).

[simsee]

Thanks Martin. I'm using Windows 10/11 (64bit). Current version of Lazarus. The problem occurs with both fpdebug and gdb. Outside of the IDE, the program throws a run-time error, without freezing the PC. The error occurs after freeing an object, so I assume it's an access violation.

[Martin_fr]

Do you get any message from the debugger at all, when the error happens?

E.g. for an access violation the IDE would normally display a dialog that the app had an access violation, and you would need to press OK.

If not start the IDE with

Code: Text  [Select][+][-]

1.  lazarus.exe   --debug-log=c:\lazlogfile.txt   --log-enable=DBG_STATE,DBG_DATA_MONITORS,DBG_ERRORS,DBG_VERBOSE,DBG_WARNINGS,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS  --debug-close-log
2.  

and submit the log. Maybe it contains any hint on what happened.


Also if you can, look at the resource usage.

If the app is killed (outside the IDE) they would all be freed). But if it is hold in the debugger, then they are still allocated (I assume).
So if the app exceeded some system wide limit for resources, then everything would need to wait, and since the debugger would never continue, that would be waiting forever.

[440bx]

Outside of the IDE, the program throws a run-time error, without freezing the PC.

Could you post a screenshot of the run-time error ?  that might be helpful.

Do you happen to have a VM installation with a different version of Windows ?... if you do, checking the behavior in a different version in a VM may also provide some clue(s).

[simsee]

When the runtime error occurs when launching the application from the IDE, no error message is displayed, and the PC needs to be restarted due to its freezing.

Outside the IDE, the classic access violation window appears (see attachment).

I'm also attaching the Lazarus log. However, I'm afraid it doesn't contain any useful information.

Thanks for your usual support.

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

1. Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] PrimaryConfigPath="C:\Users\simsee\AppData\Local\lazarus"
2. Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] SecondaryConfigPath="C:\lazarus"
3. InitializeFppkg failed: Could not find a fpc executable in the PATH
4. Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-win64-win32 New=x86_64-win64-win32 Changed: OS/CPU=True LCL=False
5. ----------------
6. Hint: (lazarus) [TMainIDE.DoOpenProjectFile] "C:\Users\simsee\Desktop\SimChart118-2\MyEditor.lpi"
7. InitOpenedProjectFile select form in designer: MainForm:TMainForm TDesigner
8. Hint: (lazarus) [TMainIDE.DoRunProjectWithDebug] INIT
9. Note: (lazarus) [TMainIDE.DoBuildProject] MainBuildBoss.DoCheckIfProjectNeedsCompilation nothing to be done
10. Hint: (lazarus) [TMainIDE.DoRunProjectWithDebug] Debugger=TFpDebugDebugger
11. Hint: (lazarus) [TMainIDE.DoRunProjectWithDebug] END

[d2010]

With the latest versions of Lazarus, the debugger freezes the PC, forcing me to shut down, when encountering certain run-time errors (typically access violations).
How can I fix this?

I have s same experienced  with Delphi2005. My program.dpr crash entire -Windows7
, when I try run debug mode for program.dpr
Always  I click/run Taskmgr.exe and I click wtib  mouse " End task/ end programe
delphi.exe"

[Martin_fr]

Ok, I am not sure what might hang Windows that badly.

And if you are up for it, I would like to try and get some more logs, but later (also involving recompiling the IDE).


Before that lets see if we can get any more detail on where the error happens.

If you compile your app (with "DWARF 2 with sets"). But do not run in the IDE.

Instead open "cmd.exe" (or a shell of your choice) and run

Code: Text  [Select][+][-]

1. gdb.exe  -ex "set confirm off" -ex r -ex bt -ex kill project1.exe

This does not need any user input. So when the app crashes the debugger isn't going to wait for any input (since input may not be possible).

It should print the stacktrace, and then kill the app.
If it can't print anything either, then try to do that, but redirect to a file and check that after reboot.

Of course if even the debugger API of the kernel is blocked then that wont work either.

[simsee]

Thanks Martin. Here my output:

(This output gives me a lot of clues as to what is causing the error in my application. I hope this helps you understand the reason for the crash from the IDE)

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

1. C:\Users\simsee\Desktop\SimChart118b>C:\lazarus\mingw\x86_64-win64\bin\gdb.exe -ex "set confirm off" -ex r -ex bt -ex kill project.exe
2. GNU gdb unicode (GDB) 9.2
3. Copyright (C) 2020 Free Software Foundation, Inc.
4. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
5. This is free software: you are free to change and redistribute it.
6. There is NO WARRANTY, to the extent permitted by law.
7. Type "show copying" and "show warranty" for details.
8. This GDB was configured as "x86_64-w64-mingw32".
9. Type "show configuration" for configuration details.
10. For bug reporting instructions, please see:
11. <http://www.gnu.org/software/gdb/bugs/>.
12. Find the GDB manual and other documentation resources online at:
13.     <http://www.gnu.org/software/gdb/documentation/>.
14.  
15. For help, type "help".
16. Type "apropos word" to search for commands related to "word"...
17. Reading symbols from project.exe...
18. Reading symbols from C:\Users\simsee\Desktop\SimChart118b\project.dbg...
19. Starting program: C:\Users\simsee\Desktop\SimChart118b\project.exe
20. [New Thread 35216.0x65ec]
21. [New Thread 35216.0x6cb0]
22. [New Thread 35216.0x3360]
23. Thread 1 received signal SIGSEGV, Segmentation fault.
24. 0x00000001001b182e in SETLEFT (this=0x5fc8eb0, VALUE=-252645131) at include/control.inc:4283
25. 4283      SetBounds(Value, FTop, FWidth, FHeight);
26. #0  0x00000001001b182e in SETLEFT (this=0x5fc8eb0, VALUE=-252645131) at include/control.inc:4283
27. #1  0x0000000100087151 in HANDLEPINENLARGEMENT (parentfp=0x13ff020) at UDrawGraph.pas:8621
28. #2  0x0000000100086c98 in MOUSEMOVE (this=0x5fc1af0, SHIFT=..., X=540, Y=693) at UDrawGraph.pas:8766
29. #3  0x000000010005f252 in MOUSEMOVE (this=0x5fc7850, SHIFT=..., X=69, Y=311) at UDrawGraph.pas:2583
30. --Type <RET> for more, q to quit, c to continue without paging--
31. #4  0x00000001001b230d in WMMOUSEMOVE (this=0x5fc7850, MESSAGE=...) at include/control.inc:4520
32. #5  0x0000000100010c1e in SYSTEM$_$TOBJECT_$__$$_DISPATCH$formal ()
33. #6  0x00000001001accd1 in WNDPROC (this=0x5fc7850, THEMESSAGE=...) at include/control.inc:2304
34. #7  0x00000001001ab7f6 in PERFORM (this=0x5fc7850, MSG=512, WPARAM=0, LPARAM=20381765) at include/control.inc:1625
35. #8  0x000000010019fa9d in ISCONTROLMOUSEMSG (this=0x5fc1af0, THEMESSAGE=) at include/wincontrol.inc:4774
36. #9  0x00000001001a0f3e in WNDPROC (this=0x5fc1af0, MESSAGE=...) at include/wincontrol.inc:5397
37. #10 0x0000000100251aa9 in DELIVERMESSAGE (TARGET=0x5fc1af0, AMESSAGE=) at lclmessageglue.pas:114
38. #11 0x0000000100181f61 in DOWINDOWPROC (this=...) at win32/win32callback.inc:2642
39. #12 0x000000010018273f in WINDOWPROC (WINDOW=132536, MSG=512, WPARAM=0, LPARAM=45416988)
40.     at win32/win32callback.inc:2807
41. #13 0x00007ffad2d0e858 in USER32!CallWindowProcW () from C:\windows\System32\user32.dll
42. #14 0x00007ffad2d0e299 in USER32!DispatchMessageW () from C:\windows\System32\user32.dll
43. #15 0x0000000100183941 in APPPROCESSMESSAGES (this=0x1579630) at win32/win32object.inc:420
44. #16 0x0000000100047c93 in HANDLEMESSAGE (this=0x1579110) at include/application.inc:1284
45. #17 0x00000001000481b7 in RUNLOOP (this=0x1579110) at include/application.inc:1427
46. #18 0x00000001000af898 in APPRUN (this=0x1579630, ALOOP=...) at include/interfacebase.inc:54
47. #19 0x000000010004817a in RUN (this=0x1579110) at include/application.inc:1415
48. #20 0x00000001000033da in main () at project.lpr:48
49. [Inferior 1 (process 35216) killed]
50. (gdb)
51.  

[Martin_fr]

Ok, glad it at least gives you some clue.

It doesn't really gives me a clue as to **IF** there is an issue in the IDE/debugger. 

I currently am not sure further logs will do either. I think the debugger is as much just victim as the rest of your desktop => something locks up the entire desktop.
If the app runs outside the debugger, then the lock is by some means released, but in the debugger, the app is frozen, holding a system wide lock to GUI interactions. => and that includes blocking the IDE debugger, which in turn blocks the app until it (the debugger) gets user input (which is never).

I played a bit.

Just crashing in MouseMove doesn't do that. Not even if I hold a MouseCapture.


Ultimately, a nice feature would be a timer in the debugger. If the debugger pauses, but the user does not interact, then it will eventually perform one last action (run or kill). But that isn't going to be anytime soon. (Also needs to be optional / possible to disable / if you wait for a long long run to reach a breakpoint, while you are away from the PC)


If it isn't crashes, you can use "debug history" to record hitting breakpoints (including watches), and keep running. And then inspect the data later. But crashes don't have that.

[Martin_fr]

With the latest versions of Lazarus, the debugger freezes the PC, forcing me to shut down, when encountering certain run-time errors (typically access violations). This didn't happen in the past with the same application. I've attached the debugger configuration of project.

This does at first indicate something in the debugger changed...

But it could also just be updates in other code in the app (LCL, any package). Even unrelated, just changing mem layout. A bad value (like the strange left value) could get a diff value. That in turn, if it goes through to the OS, could hit a driver for the graphic card, and that could hang the OS. Not the likeliest. But seen stranger things.

Especially since GDB is also affected. Well, you probably did not test that before the update... But the gdb debugger didn't really change. And that both debuggers crash....

Of course, it could be a change in the IDE part. I.e. how the IDE reports the crash. If that calls the Win-API in some way, that conflicts with the state of the crashed app. But that will be hard to avoid. The debugger/IDE can't know all the "unstable" states of the OS. It must assume that when the app pauses (including crash), then the IDE can fully interact with the user.

[simsee]

Dear Martin, thank you for your very thorough explanations. Using gdb with the command line, I found the bug I was looking for.

As soon as I have a moment, I'm curious to see if this problem occurs under Linux.