It's not entirely clear to me what's going on here, and I'm only
half-certain that this fixes the issue, due to it being somewhat hard to
reproduce. However, here's what I suspect is going on. Because we're
passing this as a pointer to various levels of function calls that might
store a reference to the pointer, Go allocates the variable on the heap.
Later, various closures are allocated on the same heap, during which
time some global Go lock is taken and W^X page permissions are twiddled
with. The Go locking then doesn't effect functions that are in win32api
calls, and at the critical moment, the variable no longer has writable
page permissions. While this might point to deeper Go runtime issues, we
just work around this here by allocating the variable using GlobalAlloc.
At the very least, I haven't been able to reproduce the bug after
applying this patch.
pravic
commented
3 years ago
Fix bug reference https://github.com/lxn/walk/pull/493
It's not entirely clear to me what's going on here, and I'm only half-certain that this fixes the issue, due to it being somewhat hard to reproduce. However, here's what I suspect is going on. Because we're passing this as a pointer to various levels of function calls that might store a reference to the pointer, Go allocates the variable on the heap. Later, various closures are allocated on the same heap, during which time some global Go lock is taken and W^X page permissions are twiddled with. The Go locking then doesn't effect functions that are in win32api calls, and at the critical moment, the variable no longer has writable page permissions. While this might point to deeper Go runtime issues, we just work around this here by allocating the variable using GlobalAlloc. At the very least, I haven't been able to reproduce the bug after applying this patch.