Crash… crash… crash…

Post AHK_H specific scripts & libraries and discuss the usage and development of HotKeyIt's fork/branch
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Crash… crash… crash…

22 Jan 2018, 20:04

Is the 1.1.27 line cursed or something…? Too many bugfixes.
1.1.27.07 is crashing a script on restart. 1.1.27.06 doesn't.
I've established the crash is due to new threads creation in the beginning of the script.

Threads are started through global var := ahkThread(" #Include *i <path-to-AHK-script> ").
Threads are terminated through var.Terminate[] before the Reload command.
I've also tried with ahkThread_Free(var), var := "" as per documentation, to no avail (Why is it online only? I want offline documentation, my connection is metered and shitty).

Is there anything more/different to do in the script to avoid the crash or is it an AHK_H bug?

Fogot to say: happening in XP-SP3 Pro x86, obviously 32bit AHK_H 1.1.27.07 (Unicode).
HotKeyIt
Posts: 1638
Joined: 29 Sep 2013, 18:35
Contact:

Re: Crash… crash… crash…

25 Jan 2018, 00:59

Can't reproduce that on Win 10, can you give me an example script.
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Crash… crash… crash…

25 Jan 2018, 04:39

A download link was already mentioned in the first post. It's KeypressOSD.
Direct download link: here
GitHub repository: here

It may not crash on Win10 but it does on XP, as mentioned. Since 1.1.27.06 and earlier don't crash the same script, it's obvious one of the latest changes triggers it. Unfortunately Dr.Watson doesn't catch it. All I can show is this:
AHKH112707crash.png
AHKH112707crash.png (60.57 KiB) Viewed 408 times

If I disable creation of one thread in the beginning of the script it will crash when trying to create the next, and so on (I put OutputDebug checkpoints before and after each thread creation).
If I completely disable creation of threads in the beginning of the script it will not crash anymore on restart.
Disabling the OnMessage() calls has no effect, it still crashes.
HotKeyIt
Posts: 1638
Joined: 29 Sep 2013, 18:35
Contact:

Re: Crash… crash… crash…

26 Jan 2018, 07:18

Unfortunately I can't test on XP for the moment, I could build you a debug version and you could try to debug using windbg or similar.
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Crash… crash… crash…

26 Jan 2018, 07:31

Minutes ago I remembered Dependency Walker, compiled the latest version of the script and ran a profiler. To my surprise, the compiled exe simply exited due to some errors. Here is the DW log of the failed launch:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus


Errors were:

Code: [Select all] [Download] GeSHi © Codebox Plus

GetProcAddress(0x7E410000 [USER32.DLL], "RemoveClipboardFormatListener") called from "KEYPRESS-OSD-AHKH 4.13.0.2.EXE" at address 0x004AB537 and returned NULL by thread 1. Error: The specified procedure could not be found (127).
GetProcAddress(0x7E410000 [USER32.DLL], "AddClipboardFormatListener") called from "KEYPRESS-OSD-AHKH 4.13.0.2.EXE" at address 0x004AB557 and returned NULL by thread 1. Error: The specified procedure could not be found (127).

There were other errors earlier:

Code: [Select all] [Download] GeSHi © Codebox Plus

GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") called from "MSVCR100.DLL" at address 0x78ABBA3B and returned NULL by thread 1. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsGetValue") called from "MSVCR100.DLL" at address 0x78ABBA48 and returned NULL by thread 1. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsSetValue") called from "MSVCR100.DLL" at address 0x78ABBA55 and returned NULL by thread 1. Error: The specified procedure could not be found (127).
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsFree") called from "MSVCR100.DLL" at address 0x78ABBA62 and returned NULL by thread 1. Error: The specified procedure could not be found (127).

This means the .bin is even worse than the main exe, which still allows the script to run uncompiled (but crashes on restart).

I have DbgView, hopefully it's good enough for debugging. Maybe DW could provide debug info too, never checked.
It'd be great if you could build that debug version (both exe and bin, to check both uncompiled and compiled). Thank you.

[EDIT]
Not even 1.1.27.06 will launch the compiled script, so the problem(s) in the bin may be much earlier than that. Oldest version I have is 1.1.25.02 and that one fails to launch the compiled script too. :(

EDIT2
Additionally, the compression options in Ahk2Exe seem to have little to no effect; there are both UPX and MPRESS in the Compiler folder, I also copied MPRESS to the main AHK folder and the Win32w folder, but the resulting exe is still 2MB (with a tiny difference of ~84kB less) and the FIleInfo plug-in in Total Commander shows no sign of compression. Encryption is disabled (don't need it). Have I gone mad…?
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Crash… crash… crash…

21 Mar 2018, 10:18

@ HotkeyIt:

I have finally found that the crash occurs in ahkThread(), more precisely when executing the conditional lines
If !(s+0!="" || s=0)
obj.hThread:=obj[IsFile?"ahkdll":"ahktextdll"](s,"",p)

Crash was reported also on Win10 x64 at the same place as on XP x86.

I have put together a most simplified debug version of the complex script that's been crashing before (KeypressOSD) where only the four threads are being loaded and nothing else. There is debug output at various stages so having a debugger running should be most welcome.

There are five main options that control the behavior of the two mouse-related threads MouseFuncThread and MouseRipplesThread:
- ShowMouseHalo ; [bool]
- ShowMouseIdle ; [bool]
- ShowMouseVclick ; [bool]
- ShowMouseRipples ; [bool]
- ShowCaretHalo ; [bool]
There is one option that controls the SoundsThread thread:
- SilentMode ; [bool] (0=enable sounds, 1=disable sounds)
There are three options that control the KeystrokesThread thread, either one can toggle it on or off:
- ShowSingleKey ; [bool]
- AltHook2keysUser ; [bool]
- DisableTypingMode ; [bool] (0=enable thread creation, 1=don't create thread)

Changing any of the above variables may not have any impact on the crashes though.

Being completely unfamiliar with objects I can't really understand what's going on in that AhkThread script and beyond, when internal AHK functions are called. One thing looked suspicious to me though, just below the (allegedly) offending line:
ahkthread_free(true)[obj]:=1
Looking at the definition of ahkthread_free() at the top, shouldn't true and obj be reversed? As in:
ahkthread_free(obj)[true]:=1
Maybe that's completely stupid, dunno, as I said I've no idea how objects work and all that - just noticed it and saying, maybe there's something to it. Anyway, I performed some tests with both versions and apparently with the second version of the call the crashes are much less frequent: 5th reload crashed with original version while only 15th reload crashed with modified version. Could be completely unrelated though.

Since ahkThread() and ahkThread_Free() are called dynamically, I had to use #include otherwise threads wouldn't work. Same for ahkExported, for some reason, although it's not called dynamically.

The package containing main test script plus thread scripts (both uncompiled and compiled x86) can be found at my repository here as ThreadCrashTest.7z.

Please tell me what else can I do to get to the bottom of this, because these crashes are a show stopper. And if I'm doing something stupid just say so, don't hold back, as long as we manage to fix the issue.
HotKeyIt
Posts: 1638
Joined: 29 Sep 2013, 18:35
Contact:

Re: Crash… crash… crash…

24 Mar 2018, 19:01

I downloaded your files and replaced MainTestScript.exe with latest AutoHotkey.exe from Win32w folder and script worked fine.
Can you please test again with latest version and let me know if it works.
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Crash… crash… crash…

25 Mar 2018, 06:25

Will do that when I get back home, now I gotta leave.
There is one other issue I noticed earlier after fixing AhkThread problem myself: the working dir gets changed after calling AhkThread() so relative paths don't work anymore.
In my example, calling AhkThread() on first script from Lib\... works, but next calls for the other three scripts at the same location fail. I had to use absolute paths to get them working. Weird.
HotKeyIt
Posts: 1638
Joined: 29 Sep 2013, 18:35
Contact:

Re: Crash… crash… crash…

25 Mar 2018, 08:06

You can call AhkThread without giving a path, it will use included dll from resources.
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Crash… crash… crash…

25 Mar 2018, 14:53

Sorry, I wasn't very clear before. It's not about AhkThread.ahk, that one does need to be #included specifically (on my system, at least) or it woudn't work at all.
What I meant was, when creating more than one thread, from different scripts, first thread gets created fine but subsequent threads do not if the files are called from relative paths. In example:

Code: [Select all] [Download] GeSHi © Codebox Plus

thread1 := AhkThread("Lib\script1.ahk",, 1)
thread2 := AhkThread("Lib\script2.ahk",, 1)
thread3 := AhkThread("Lib\script3.ahk",, 1)

After thread1 gets created, thread2 and thread3 will fail because files cannot be found. If instead I do:

Code: [Select all] [Download] GeSHi © Codebox Plus

thread1 := AhkThread("Lib\script1.ahk",, 1)
SetWorkingDir, %A_ScriptDir%
thread2 := AhkThread("Lib\script2.ahk",, 1)
SetWorkingDir, %A_ScriptDir%
thread3 := AhkThread("Lib\script3.ahk",, 1)

they will all be created.
Otherwise I'd have to do:

Code: [Select all] [Download] GeSHi © Codebox Plus

thread1 := AhkThread(A_ScriptDir "\Lib\script1.ahk",, 1)
thread2 := AhkThread(A_ScriptDir "\Lib\script2.ahk",, 1)
thread3 := AhkThread(A_ScriptDir "\Lib\script3.ahk",, 1)

which works correctly too.
No idea why this happens. And it's all about running uncompiled, in this setup. When compiled, thread scripts are being retrieved from resources and we hit the other issue with StrGet() (and FileAppend, if needed for debugging purposes).
User avatar
Drugwash
Posts: 512
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: Crash… crash… crash…

26 Mar 2018, 04:00

Ah, thank you very much for this information. I had changed working dir in a thread script at some point due to an icon issue or something and that screwed everything up. I thought each thread would retain its own working dir same as A_ScriptDir but apparently that is not the case in multithreaded environments.
Thanks again.

Return to “AutoHotkey_H”

Who is online

Users browsing this forum: No registered users and 1 guest