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>

1 files changed, 7 insertions, 6 deletions

diff --git a/form.go b/form.go
index 48e93d55..6b7e3e0c 100644
--- a/form.go
+++ b/form.go
@@ -393,10 +393,11 @@ func (fb *FormBase) Run() int {
 		}
 	}
 
-	var msg win.MSG
+	msg := (*win.MSG)(unsafe.Pointer(win.GlobalAlloc(0, unsafe.Sizeof(win.MSG{}))))
+	defer win.GlobalFree(win.HGLOBAL(unsafe.Pointer(msg)))
 
 	for fb.hWnd != 0 {
-		switch win.GetMessage(&msg, 0, 0, 0) {
+		switch win.GetMessage(msg, 0, 0, 0) {
 		case 0:
 			return int(msg.WParam)
 
@@ -406,14 +407,14 @@ func (fb *FormBase) Run() int {
 
 		switch msg.Message {
 		case win.WM_KEYDOWN:
-			if fb.webViewTranslateAccelerator(&msg) {
+			if fb.webViewTranslateAccelerator(msg) {
 				// handled accelerator key of webview and its childen (ie IE)
 			}
 		}
 
-		if !win.IsDialogMessage(fb.hWnd, &msg) {
-			win.TranslateMessage(&msg)
-			win.DispatchMessage(&msg)
+		if !win.IsDialogMessage(fb.hWnd, msg) {
+			win.TranslateMessage(msg)
+			win.DispatchMessage(msg)
 		}
 
 		runSynchronized()