Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Show error or debug dialog on Call Stack overflow


  • Please log in to reply
6 replies to this topic
fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Right now AHK is simply stopping its process when a call stack overflow occurs. I think it would be beneficial when an error message could be shown, best would be a line number with an optional stack trace. If this is not possible due to technical limitations (as in, no stack space available anymore... ;) ), throwing a non-catched exception might be good so that one can atleast debug it in Visual Studio to find the proper line of code in the script that caused it.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
AutoHotkey doesn't specifically stop its process; a stack overflow exception is automatically thrown and not handled, so the process terminates. AutoHotkey doesn't place any specific limits - it just happens when program stack space runs out.

Showing a specific line of code could be misleading, since the exception is thrown when stack space runs out. That is, the line which was executing might not be the line which caused recursion; and might not even be related. A simple stack trace might be possible, relying on the "stack" maintained for the debugger.

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
Why is it that Windows is not showing a "This process has stopped working ..." dialog instead of terminating the process?

I only see the exception when I run a debug build with the debugger attached.

A callstack print would be very good for the scripter to locate the bug indeed.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Why is it that Windows is not showing a "This process has stopped working ..." dialog instead of terminating the process?

Your wording is confusing, and your question makes little sense. If the "program has stopped working" message appears, the process is terminating or has already terminated. If you meant to merely ask why Windows doesn't show a message, I don't know. I assume its up to the OS and system configuration. I think it has something to do with the Windows Error Reporting service.

I only see the exception when I run a debug build with the debugger attached.

Generally, if the process terminates due to an unhandled exception, the process' exit code is the exception code. For instance, if I run...
Label:
gosub Label
...in SciTE, it shows the exit code as -1073741819. Converted to unsigned hexadecimal, that is 0xC0000005 (access violation). I was expecting 0xC00000FD (stack overflow)...

fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
That's what I meant, sorry for being unclear. I see these error dialogs on other errors in AHK, such as invalid DLLCalls, so I was just wondering why they don't appear on stack overflows.

I tried the code you posted and it shows a call stack overflow code in SciTE for me.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
I was on XP; on my 7 x64 system, I get -1073741571 (stack overflow).

I found that I only get an error reporting dialog if I run a 64-bit AutoHotkey.exe. Either way, there was a long delay between when the error actually occurs and when the process terminates or the dialog appears.

I changed the settings in the Windows 7 Action Center to "Never check for a solution", and now most times I instantly get a message saying that AutoHotkey has stopped working. If it is set to "ask me before checking for a solution", it also says I can check online for a solution. The default/recommended setting "Automatically check for solutions" causes the process to silently terminate (after the delay) in some cases.

You can see what's going on by setting the "always show UI" flag:
DllCall("WerSetFlags", "uint", 16)  ; Vista+
Label:
gosub Label

A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
[Close program]

Additional details about what went wrong can help Microsoft create a solution.
[Send information] [Cancel]



fragman
  • Members
  • 1591 posts
  • Last active: Nov 12 2012 08:51 PM
  • Joined: 13 Oct 2009
I'm not on x64 right now, but I couldn't manage to get the 32bit message you posted with your example script and the "Never check for a solution" option. It just silently exits.