The meaningless "Invalid memory read/write"

[crocodile]

I encountered this error frequently after I started using V2. When reading and writing objects, when calling DllCall(), when calling RegExMatch(). But apparently these error reports are meaningless because it doesn't tell us exactly what error happened.
I'm a little curious as to why I never encountered this error in V1. Why is it so ubiquitous in V2?
Yes, I searched the forums and found a lot of "Invalid memory read/write" related problems. And apparently the solutions to these problems have nothing to do with memory, and this error only causes confusion and misunderstanding.

Critical Error: Invalid memory read/write.


▶ 067: If RegExMatch(st, "i)\b([a-zA-Z0-9]{40})\b", &v)


The program is now unstable and will exit.

Because of this error, I abandoned a script that I had been using for years. When I updated it to the latest V2 version, it started to have a small chance of error, but apparently I couldn't figure out the cause of the error, so I had to give up using it.

Critical Error: Invalid memory read/write.

▶ 024: g_hwnd[hwnd] := { class: class, exe: exe, hwnd: hwnd}

It should be noted that all codes with "Invalid memory read/write" errors are codes that work properly for a long time, and the errors only occur occasionally with a small chance.

[swagfag]

option:

1. uve found genuine v2 bugs. in which case u should post the script thats causing them, so they can be fixed
2. u were running a pre-v1.1.33.00 ahk version, which doesnt feature SEH handling. in which case, ur scripts would have simply crashed silently(and possibly u werent even aware that was happening)
3. uve ported the v1 code wrong
4. the v1 code was written wrong to begin with(and B. was in effect)

without any concrete examples to look at this thread is mostly pointless

[crocodile]

@swagfag
My script may have an error once every three days, during which time everything may be fine no matter how much you test it. It doesn't make sense to release the code in this case. And I'm also convinced that my code itself is error-free, just like the second reported error.

I think the real problem is that the line of code to which the error refers is clearly not in error. I spent a lot of time rewriting that script, even modifying it to look like this, and it still reports an error.

Critical Error: Invalid memory read/write.

t := { class: class, exe: exe, hwnd: hwnd}
if g_hwnd is Map && hwnd is Integer
▶ 024: g_hwnd[hwnd] := t

Metaphorically speaking, if you encountered this error once a month, how would you solve it?

Critical Error: Invalid memory read/write.

▶ 01: MsgBox 123

[swagfag]

• download visual studio
• download the ahk source
• compile a fulldebug build with fulldebug symbols
• enable per-application fulldump(type=2) collection https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
• use ur compiled debug.exe to run ur ahk script
• wait until it crashes(u wont get an error dialog though, since its debug build)
• analyze the resulting dmp with windbg and see which line it crashed on

then u can start thinking about what might have caused it

[crocodile]

1, this thread is not looking for help, the topic is "Error reporting is meaningless"
2, I can't use this complicated process to debug ahk code. If all AutoHotkey users have to master this complex debugging method to use AutoHotkey, then I will try it.
3, even if I use this complex debugging process, I am skeptical that the problem will be reproduced in a debug environment.
4, I accept that my AutoHotkey crashes directly or reports an "unknown error", but I can't accept "Invalid memory read/write".

[swagfag]

1, this thread is not looking for help, the topic is "Error reporting is meaningless"

and u know its meaningless becaaaause??? because uve found out whats actually causing the error and have determined it wasnt due to an "Invalid read/write"? as far as i understood, u have no clue whatsoever whats causing the crashes. so how did u figure the error message was meaningless? because it doesnt point to the exact place where the error occurred? it doesnt have to. in fact, in some cases, particularly if you are for example trampling memory u shouldnt be touching or are misusing APIs which in turn mangle memory regions due to your having passed incorrect parameters(eg sizes, buffer lengths, char counts, etc), the damage done need not be immediately apparent. it may be only much later, whenever something ends up needing to touch the trampled memory region that the error may or may not manifest itself

2, I can't use this complicated process to debug ahk code. If all AutoHotkey users have to master this complex debugging method to use AutoHotkey, then I will try it.

¯\_(ツ)_/¯ complicated scripts, complicated debugging processes. u can try cutting parts out of script and testing them in isolation(using whichever methods u happen to like), but ud waste a whole lot more time doing that. and in the end its not even guaranteed ud find anything anyway

3, even if I use this complex debugging process, I am skeptical that the problem will be reproduced in a debug environment.

¯\_(ツ)_/¯ u can be skeptical all u like, i cant help with that. im not here to convince anyone

4, I accept that my AutoHotkey crashes directly or reports an "unknown error", but I can't accept "Invalid memory read/write".

why? the error is the same in all cases - STATUS_ACCESS_VIOLATION 0xC0000005. it says "Invalid memory read/write" because in the grand majority of cases that is what would be causing such an error. for the end-user, this error message is simple and understandable. "unknown error" is not, its even more meaningless. and ur first preference of ignoring the error and letting ahk crash silently is completely unacceptable as a default behavior in a language that allows u to DllCall any random shit u may think of and fiddle with memory any which way u like. in your scripts, u may override this behavior with ur own custom onerror handler if u dont like seeing the error dialog that much, eg:

Code: Select all

OnError((Thrown, Mode) => Mode == 'ExitApp')

[crocodile]

About debugging. A few years ago I tried to compile the debug version and spent a lot of time without success. Then I was lucky enough to find a version compiled by HotKeyIt, but I still haven't figured out the problem, because although I was able to communicate with you with the help of translation software, debug.exe was only available in English and I couldn't use it properly. And of course I didn't reproduce my problem in a debug environment. I say all this to show how difficult this debugging process is for a layman with no programming foundation.
I can understand compiled languages looking for problems with debug.exe. But a scripting language, a line of perfectly correct code to report an error, but only through debug.exe to find the real problem, I can not understand.

Unless someone can tell me what exactly is wrong with this line of code and how to modify it to not report an error.
If RegExMatch(st, "i)\b([a-zA-Z0-9]{40})\b", &v)
Reporting an error on a normal line of code that meets all the rules and throwing the underlying problem of the scripting language at the user is hard to understand.

[thqby]

As far as I know, invalid memory reads and writes sometimes do not immediately display an error. An error will be triggered when the memory is accessed again, and the source of the error is difficult to locate at this time.

Not only ahk, but also other scripting languages that can freely operate memory and use external languages will have this problem.

If it is not caused by user code, it may be a bug.

[crocodile]

I'm about to be driven crazy by this question.
I feel like the "Invalid memory read/write" character is fooling me, when it's more directly meant to say: go away, you don't deserve to use AutoHotkey.
Why do I want AutoHotkey to crash immediately? Because then I know AutoHotkey can't execute this code correctly and I should give up on AutoHotkey.

[guest3456]

Unless someone can tell me what exactly is wrong with this line of code and how to modify it to not report an error.
If RegExMatch(st, "i)\b([a-zA-Z0-9]{40})\b", &v)

how do you use the v variable prior? perhaps that is the problem?

Reporting an error on a normal line of code that meets all the rules and throwing the underlying problem of the scripting language at the user is hard to understand.

+1

[lexikos]

The error dialog shows the line that was executing when the error occurred. This could be because the line did something it shouldn't, or it could be because the state of the program is corrupt due to errors elsewhere in the script or program. It is simply the nature of this error that sometimes the line and stack trace are relevant and sometimes it is not.

For example: The line If RegExMatch(st, "i)\b([a-zA-Z0-9]{40})\b", &v) is "semi-compiled" to a bunch of internal structures resembling code, before the script executes. Suppose that some of these structures are overwritten by some poorly-written DllCall code. When that line needs to execute, the program can't possibly be expected to execute according to its normal logic, because something has unexpectedly corrupted it. This is a risk you take when using DllCall or NumPut. The language could prevent such errors, but only by taking DllCall away and making AutoHotkey less flexible. If native code attempts to write to a location which is not writable, it will raise an exception, which the program will catch and display to you. In this hypothetical case, the location is writable, so the native code just executes and returns, and the error is not detected at its origin.

Sometimes the cause is not improper use of DllCall, but a bug in the program. In that case, at the very least, we would need code to reproduce the issue.

[crocodile]

I've noticed that I haven't encountered this error in a long time, and it seems to have been fixed at #325.

https://github.com/AutoHotkey/AutoHotkey/pull/325

[20170201225639]

I'm on version 2.0.5. and I still see this occasionally (from what I know is bad code convered from v1 that I haven't gotten round to fixing).

I actually *thought* I had something reproducible a minute ago, because I was able to repeat it 4 times. But now it only happens like half of the time.

This is what's caught by OnError (I split the "Stack" property's value by CRLF). What does "> Callback" mean?

(Line #978 is just a lone a closing curly bracket!)

Code: Select all

{
 "Mode": "ExitApp",
 "Thrown": {
  "Extra": "",
  "File": "C:\\@CS\\ahk\\@ahk.ahk",
  "Line": 978,
  "Message": "Invalid memory read/write.",
  "Stack": [
   "> Callback",
   ""
  ],
  "What": ""
 },
 "Type": "Error"
}

[lexikos]

A thread was being started from a callback (created with CreateCallback).

[20170201225639]

I see, thanks lexicos. The only such callback in my code is from SetWinEventHook, so that's probably where I should investigate.

Code: Select all

DllCall("user32\SetWinEventHook", "UInt", 0x0003, "UInt", 0x0003, "Ptr", 0, "Ptr", CallbackCreate(WM_EventHookCallBack), "UInt", 0, "UInt", 0, "UInt", 0, "Ptr")