18 replies to this topic

[stevenp]

One of my scripts is crashing every day and the crash happens not consequently, not after a certain Hotkey or selected menu item. Every time it happens in different circumstances
Is there a way to determine Last Line which was executed before the crash?

Maybe there a script available which will add a Log() line before each line, but without breaking script functionality by checking syntax of each line.
For example, following will work

if a=b {
  Log("SCRIPTNAME LINE# : if a=b {")
  b := c  
  Log("SCRIPTNAME LINE# : b := c")
}
Log("SCRIPTNAME LINE# : }")

but following will be incorrect:

if a=b
  Log("SCRIPTNAME LINE# : if a=b")
  b := c  
  Log("SCRIPTNAME LINE# : b := c")

probably additional information would be helpful too, like cpu/memory usage, current A_ThisFunction, etc.

Please share some experience to solve Crashing issues.

[dylan904]

In your second code, either put the lines within the if statement in brackets, or re-align them, because if they aren't inside brackets only the first line after the if statement will be considered when executing. After that, the lines will execute regardless.

[stevenp]

a script which would add a Log() function after each line in the script should determine whether currently parsed line is an if statement and whether there's a continuation section, so probably at least two lines should be scanned.
Is someone already have some script like that?
Hopefully with a reverse function (delete Log() functions)

[MasterFocus]

Here's a related topic (not sure if you seen it):
"Show error or debug dialog on Call Stack overflow" - <!-- l --><a class="postlink-local" href="http://www.autohotkey.com/community/viewtopic.php?f=4&t=89813">viewtopic.php?f=4&t=89813</a><!-- l -->

[stevenp]

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.

That's right Lexikos, the whole idea with the Log() is useless.
Is it possible to find out the stack overflow in Scite4Ahk?
I can see the stack only if some breakpoints are in the script, otherwise it's empty.
Am I have to put hundreds of breakpoints everywhere in the script?

[Lexikos]

Is it possible to find out the stack overflow in Scite4Ahk?

Stack overflow = a particular kind of error involving the stack.
Call stack = the stack of running functions.
I think you mean the latter.

I can see the stack only if some breakpoints are in the script, otherwise it's empty.

The call stack can only be retrieved while the script is in a "break" state; i.e. after it hits a breakpoint or after you've "stepped" (using one of the green arrows on the toolbar). Immediately after you start debugging or after hitting a breakpoint, you can step through the code one line at a time using the first green arrow (or the F10 key).

[stevenp]

Step-debugging is not appropriate here, it looks like the problem within a particular timer subroutine, after disabling it there was no crash since yesterday.
But there is no goto/gosub within that timer. If I place a breakpoints within that timer, it's impossible to work, because the script is paused and there's nothing to see in the Callstack. The crash happens in 1-6 hours period. Any ideas?

[stevenp]

It looks like nobody have a solution, so autohotkey v1 is not ready for such hard cases. Hopefully v2 will not be so error-prone and such stack-related errors will be catched by the interpreter and there will be a #Warn, instead of a spit.

[Lexikos]

What makes you think the error is stack-related?

Since you already know the problem is somewhere in your timer subroutine, it shouldn't be too much trouble to add debugging code every few lines to narrow down the problem. You could write to a log file or OutputDebug. When the script crashes, see what the last log/debug entry was.

[stevenp]

it shouldn't be too much trouble to add debugging code every few lines to narrow down the problem

it's impossible, because

The crash happens in 1-6 hours period

You could write to a log file or OutputDebug. When the script crashes, see what the last log/debug entry was.

That's what I'm working on now - assigning a identifier log(id:=A_TickCount,A_ThisFunction,"Comment") to every called function in order to add indentation to every log(id,"text") called within the function, and then holding a static array[] of these identifiers within log(), but it's quite complicated when a thread (hotkey or timer) interrupts another thread, the log file becomes inconsistent.

I thought I could use DynaRun to log each executed line and to see the last executed line and the full history.

[Lexikos]

it's impossible

Should I say that helping you is impossible, so I give up?

Adding logging every few lines in a single timer subroutine is guaranteed to produce a smaller log file than adding logging after every line, as in your original request. If the log file becoming large is somehow a problem, work around it by trimming older log entries. If you use OutputDebug and DebugView, you can limit how much output it retains. You don't need to read the entire log anyway; just the last entries.

Maybe you weren't talking about how large the log file would grow in 1-6 hours, but I can't see how else the infrequency of the crash would have any relevance.

[stevenp]

No, no, I started the thread to get some advice.
Log files were split in a form A_MM "-" A_DD "\" A_Hour " h.log"
The problem wasn't in the timers. Log files are not helpful in this case. After searching and replacing, where it was possible, almost all goto-gosub-label-return structures with loops throughout all the scripts and functions, ahk is not crashing now even after enabling the timers. Unfortunately I can't say which one label exactly triggered the crash. The timers are just accelerated the inevitable crash.

What I would like to see in future versions of your Ahk_L interpreter is ability to catch such goto-gosub-label-return errors (iterative?), because the only advice appropriate here is to avoid using them, they're Dangerous
But because there's no sample script to reproduce the crash, there's nothing to fix.
Thanks for trying to help!

[Lexikos]

What I would like to see in future versions of your Ahk_L interpreter is ability to catch such goto-gosub-label-return errors (iterative?), because the only advice appropriate here is to avoid using them, they're Dangerous

[*:1ap33os0]Used in the wrong hands, almost anything can be dangerous.
[*:1ap33os0]Warning people away from those extremely basic programming tools would not be productive.
[*:1ap33os0]By removing those from your script, you have changed the flow of the script. The problem may have had nothing at all to do with "goto-gosub-label-return".
[*:1ap33os0]The only way that gosub can directly crash the script is to have a label gosub into itself, or similar recursive call (e.g. A calls B, B calls C, C calls A). This can be called "infinite recursion".

[stevenp]

Used in the wrong hands, almost anything can be dangerous.

You could ask for the sources for observation but you would not find any syntax errors

Warning people away from those extremely basic programming tools would not be productive.

All right, will rephrase my opinion: avoid using very often the goto-gosub-return structures in long 5-10K+ scripts, because it will be a nightmare to find out which one causes ahk to scream.

By removing those from your script, you have changed the flow of the script. The problem may have had nothing at all to do with "goto-gosub-label-return".

The flow remain the same, labels was replaced with loop-break and if-else structures and additional variables created.

The only way that gosub can directly crash the script is to have a label gosub into itself, or similar recursive call (e.g. A calls B, B calls C, C calls A). This can be called "infinite recursion".

Probably that was the case, and such rude error is not catched by the interpreter. Probably testing this would slowdown ahk execution

[Lexikos]

All right, will rephrase my opinion: avoid using very often the goto-gosub-return structures in long 5-10K+ scripts, because it will be a nightmare to find out which one causes ahk to scream.

My idea of a nightmare is a 5-10K+ script which does not make use of subroutines or functions to organize the code.

The flow remain the same,

If the flow was the same, it would still be crashing.

Probably that was the case,

If so, the crash exception code is probably 0xc00000fd (stack overflow). If you are on Windows 7, you can use the Reliability Monitor to check. On an English system, type reliability into Start search and click on View reliability history. Then find the critical event corresponding to your AutoHotkey.exe crash, and click View technical details (in the Action column), and look for Exception code. My instructions may need to be "translated" for non-English systems.



I wasn't aware of this tool until recently.

You could ask for the sources for observation but you would not find any syntax errors

Oh? Obviously you were doing something wrong.