summaryrefslogtreecommitdiffstatshomepage
path: root/groupbox.go
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2019-04-27 14:40:25 +0200
committerJason A. Donenfeld <Jason@zx2c4.com>2019-04-27 14:40:25 +0200
commitc0622b16b919b171be6900d6ba4cd6f17117ed3b (patch)
tree16a58e73118c23f9bac6c3104b55cdfaa2b53e19 /groupbox.go
parentImageView: Default to transparent background (diff)
downloadwireguard-windows-c0622b16b919b171be6900d6ba4cd6f17117ed3b.tar.xz
wireguard-windows-c0622b16b919b171be6900d6ba4cd6f17117ed3b.zip
form: don't use Go heap for MSG
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. Fixes: #483 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'groupbox.go')
0 files changed, 0 insertions, 0 deletions