[Bug 36695] New: 64-bit binaries produced by Go produce lots of create_view messages and an eventual unhandled page fault, even if the program already finished running successfully
http://bugs.winehq.org/show_bug.cgi?id=36695
Bug ID: 36695 Summary: 64-bit binaries produced by Go produce lots of create_view messages and an eventual unhandled page fault, even if the program already finished running successfully Product: Wine Version: 1.7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: pietro10@mac.com
Created attachment 48734 --> http://bugs.winehq.org/attachment.cgi?id=48734 Output of the hello, world program in the post.
wine seems to have a problem loading 64-bit binaries produced by the Go compiler for target windows/amd64 (GOOS=windows GOARCH=amd64).
First, on startup, wine prints a lot of messages of the form
fixme:virtual:create_view out of memory in virtual heap for 0x5c000000000-0x5c882002000
with different addresses each time. Then, the program starts running, often to completion (echo $? gives 0). At the same time, wine says
wine: Unhandled page fault at address 0x7f7f46f5b33f (thread 0029), starting debugger...
and tries to quit. (Smaller programs like the attached may not produce this message; the longer the program, the more likely it is to appear.) For small programs, the program code will race wine and succeed; larger programs will just not work.
Sometimes, the Unhandled page fault is accompanied by a messagebox with title "Wine program crash" and text "Internal errors - invalid parameters received".
The attachment is the output of
package main import "fmt" func main() { fmt.Println("hello, world") }
This is with wine from the official Ubuntu PPA. This has happened over many Go versions from the past few months; the one I used here is
go version go1.3beta2 +aecdc70c44ac Fri May 23 17:39:58 2014 -0700 linux/amd64
http://bugs.winehq.org/show_bug.cgi?id=36695
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |win64 CC| |focht@gmx.net Summary|64-bit binaries produced by |64-bit binaries produced by |Go produce lots of |Go compiler for |create_view messages and an |windows/amd64 target crash |eventual unhandled page | |fault, even if the program | |already finished running | |successfully |
--- Comment #1 from Anastasius Focht focht@gmx.net --- Hello Pietro,
can you attach a simple test binary which exhibits the crash?
Regards
http://bugs.winehq.org/show_bug.cgi?id=36695
--- Comment #2 from Pietro Gagliardi (andlabs) pietro10@mac.com --- Created attachment 48736 --> http://bugs.winehq.org/attachment.cgi?id=48736 Executable for the hello, world example, as requested (extracts to 1.9MB)
Sure. Here's the binary for the hello, world program in the first post/that generated hello.out.
http://bugs.winehq.org/show_bug.cgi?id=36695
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Summary|64-bit binaries produced by |64-bit binaries produced by |Go compiler for |Go compiler for |windows/amd64 target crash |windows/amd64 target crash | |(stack pointer (RSP) must | |be 16-byte aligned when | |making a call to Win64 API)
--- Comment #3 from Anastasius Focht focht@gmx.net --- Hello Pietro,
thanks for the binary.
'fixme:virtual:create_view out of memory in virtual heap for' messages are unrelated and sort of expected.
The Go runtime initially tries to reserve an insane amount of virtual memory address space (128 GB) at different ranges and finally falls back to more reasonable values after failing get that much from OS.
See the glory details here: https://code.google.com/p/go/source/browse/src/pkg/runtime/malloc.goc#471
I had to restrain myself from making a witty comment here. Anyway, the heap manager setup succeeds in the end:
--- snip --- Wine-dbg> ... 0x000000000042750b _rt0_go+0x11b in hello: call 0x0000000000412090 runtime.schedinit ... 0x00000000004120bb runtime.schedinit+0x2b in hello: movb $0x1,0x0000000000561409 runtime.precisestack 0x00000000004120c3 runtime.schedinit+0x33 in hello: call 0x00000000004260d0 runtime.symtabinit 0x00000000004120c8 runtime.schedinit+0x38 in hello: call 0x0000000000422580 runtime.mallocinit ... 0x00000000004225c8 runtime.mallocinit+0x48 [/home/pietro/go/src/pkg/runtime/compiler.go:1] in hello: call 0x000000000040daf0 runtime.InitSizes ... --- snip ---
--- snip --- ... 0023:Call KERNEL32.VirtualAlloc(00000000,882002000,00002000,00000004) ret=00429d9a 0023:fixme:virtual:create_view out of memory in virtual heap for 0x7f766f380000-0x7f7ef1382000 0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=00429d9a 0023:Call KERNEL32.VirtualAlloc(00600000,28202000,00002000,00000004) ret=00429d9a 0023:Ret KERNEL32.VirtualAlloc() retval=00600000 ret=00429d9a ... --- snip ---
The Go runtime creates a second thread which crashes while trying to call native API:
--- snip --- ... 0023:Call KERNEL32.DuplicateHandle(ffffffffffffffff,fffffffffffffffe,ffffffffffffffff,0023fca0,00000000,00000000,00000002) ret=00429d9a 0023:Ret KERNEL32.DuplicateHandle() retval=00000001 ret=00429d9a 0023:Call KERNEL32.GetSystemTimeAsFileTime(003a3cc8) ret=00429d9a 0023:Ret KERNEL32.GetSystemTimeAsFileTime() retval=003a3cc8 ret=00429d9a 0023:Call KERNEL32.CreateThread(00000000,00020000,00429fb0,0881e000,00010000,00000000) ret=00429d9a 0023:Ret KERNEL32.CreateThread() retval=00000060 ret=00429d9a 0023:Call KERNEL32.GetSystemTimeAsFileTime(003a3b98) ret=00429d9a 0023:Ret KERNEL32.GetSystemTimeAsFileTime() retval=003a3b98 ret=00429d9a 0023:Call KERNEL32.GetSystemTimeAsFileTime(003a3da0) ret=00429d9a 0023:Ret KERNEL32.GetSystemTimeAsFileTime() retval=003a3da0 ret=00429d9a 0023:Call KERNEL32.VirtualAlloc(00000000,00100000,00003000,00000004) ret=00429d9a 0023:Ret KERNEL32.VirtualAlloc() retval=28a70000 ret=00429d9a ... 0024:Starting thread proc 0x429fb0 (arg=0x881e000) ... 0024:Call KERNEL32.DuplicateHandle(ffffffffffffffff,fffffffffffffffe,ffffffffffffffff,28a6e508,00000000,00000000,00000002) ret=00429d9a ... 0024:Ret KERNEL32.DuplicateHandle() retval=00000001 ret=00429d9a ... 0024:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7f7ef9521c22 ip=7f7ef9521c22 tid=0024 0024:trace:seh:raise_exception rax=00007f7ef94c8340 rbx=ffffffffffffff38 rcx=00007f7ef97a1958 rdx=0000000000030122 0024:trace:seh:raise_exception rsi=0000000028a6e3d0 rdi=000000000881a120 rbp=0000000028a6e428 rsp=0000000028a6e338 0024:trace:seh:raise_exception r8=0000000028a6e4a0 r9=000000000000001d r10=0000000000000000 r11=0000003157381420 0024:trace:seh:raise_exception r12=0000000028a6e4c0 r13=000000000881e000 r14=000000000881a120 r15=000000000881e060 0024:trace:seh:call_vectored_handlers calling handler at 0x429e30 code=c0000005 flags=0 0024:trace:seh:call_vectored_handlers handler at 0x429e30 returned 0 --- snip ---
Debugging session:
--- snip --- Wine-dbg> ... 0x000000000041319e runtime.mstart+0xbe in hello: call 0x0000000000427530 runtime.asminit 0x00000000004131a3 runtime.mstart+0xc3 in hello: call 0x000000000040ea40 runtime.minit 0x00000000004131be runtime.mstart+0xde in hello: jnz 0x00000000004131c5 runtime.mstart+0xe5 0x00000000004131e0 runtime.mstart+0x100 in hello: jz 0x00000000004131fb runtime.mstart+0x11b 0x00000000004131f9 runtime.mstart+0x119 in hello: calll *%eax ... 0x0000000000417450 sysmon in hello: movq %gs:0x0000000000000028,%rcx ... 0x00000000004174a9 sysmon+0x59 in hello: call 0x000000000040ed20 runtime.usleep ... 0x000000000040ed2e runtime.usleep+0xe in hello: call 0x000000000042a000 runtime.usleep1 ... 0x000000000042a054 runtime.usleep1+0x54 in hello: calll *%eax
Wine-dbg>info reg Register dump: rip:000000000042a054 rsp:0000000028a6e4b8 rbp:000000000881e000 eflags:00000346 ( - -- IT Z- -P- ) rax:000000000042a080 rbx:00000000000000c8 rcx:0000000000000014 rdx:0000000028a6e508 rsi:0000000028a6e3d0 rdi:000000000881a120 r8:0000000000000040 r9:0101010101010101 r10:0000000000000008 r11:0000000000000246 r12:0000000028a6e4c0 r13:000000000881e000 r14:000000000881a120 r15:000000000881e060 ... Wine-dbg>si 0x000000000042a097 runtime.usleep2+0x17 in hello: movq 0x000000000055a970 runtime.NtWaitForSingleObject,%rax ... Wine-dbg>si 0x000000000042a09f runtime.usleep2+0x1f in hello: calll *%eax
Wine-dbg>info reg Register dump: rip:000000000042a09f rsp:0000000028a6e4a8 rbp:000000000881e000 eflags:00000346 ( - -- IT Z- -P- ) rax:00007f395dbe2fcc rbx:ffffffffffffff38 rcx:ffffffffffffffff rdx:0000000000000000 rsi:0000000028a6e3d0 rdi:000000000881a120 r8:0000000028a6e4a8 r9:0101010101010101 r10:0000000000000008 r11:0000000000000246 r12:0000000028a6e4c0 r13:000000000881e000 r14:000000000881a120 r15:000000000881e060
0x00007feee1d23e7b NtWaitForMultipleObjects+0x6 [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/sync.c:854] in ntdll: subq $0x1b0,%rsp 854 {
Wine-dbg>info reg Register dump: rip:00007feee1d23e7b rsp:0000000028a6e448 rbp:0000000028a6e458 eflags:00000302 ( - -- IT - - - ) rax:0000000028a6e4a8 rbx:ffffffffffffff38 rcx:0000000000000001 rdx:0000000028a6e4a8 rsi:0000000028a6e3d0 rdi:000000000881a120 r8:0000000000000000 r9:0000000000000000 r10:0000000000000008 r11:0000000000000246 r12:0000000028a6e4c0 r13:000000000881e000 r14:000000000881a120 r15:000000000881e060 ... Wine-dbg>si fixme:dbghelp_dwarf:parse_cie_details unknown CIE version 3 at 0x2499008 fixme:dbghelp_dwarf:parse_cie_details unknown CIE version 3 at 0x2499008 0x00007feee1d23e82 NtWaitForMultipleObjects+0xd [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/sync.c:854] in ntdll: 854 {
Wine-dbg>si
err:seh:call_stack_handlers invalid frame 881e010 (0x28972000-0x28a70000) Unhandled exception: page fault, invalid program stack in 64-bit code (0x00007feee1d23e82). fixme:dbghelp_dwarf:parse_cie_details unknown CIE version 3 at 0x2499008 fixme:dbghelp_dwarf:parse_cie_details unknown CIE version 3 at 0x2499008 Register dump: rip:00007feee1d23e82 rsp:0000000028a6e298 rbp:0000000028a6e458 eflags:00010302 ( R- -- IT - - - ) rax:0000000028a6e4a8 rbx:ffffffffffffff38 rcx:0000000000000001 rdx:0000000028a6e4a8 rsi:0000000028a6e3d0 rdi:000000000881a120 r8:0000000000000000 r9:0000000000000000 r10:0000000000000008 r11:0000000000000246 r12:0000000028a6e4c0 r13:000000000881e000 r14:000000000881a120 r15:000000000881e060 Stack dump: 0x0000000028a6e298: 0000000000000000 0000000028a6e3d0 0x0000000028a6e2a8: fffffffffffffffe 0000000028a6e3c0 0x0000000028a6e2b8: 000000007b882974 ffffffffffffffff 0x0000000028a6e2c8: fffffffffffffffe ffffffffffffffff 0x0000000028a6e2d8: 0000000028a6e508 0000000000000000 0x0000000028a6e2e8: 00007fee00000000 0000000000000002 0x0000000028a6e2f8: 00007feeda1eaab5 00007feeda0b0000 0x0000000028a6e308: 0000000000000002 0000000080000004 0x0000000028a6e318: 0000000000000000 00007feee1d23e7b 0x0000000028a6e328: 0000000000000000 00007feee1d23e7a 0x0000000028a6e338: 0000000000000000 00007feee1d23e75 0x0000000028a6e348: 0000000000000000 ffffffffffffffff Backtrace:
=>0 0x00007feee1d23e82 NtWaitForMultipleObjects+0xd(count=0x10970, handles=0xffffffffffffffff, wait_all=-98, alertable=0, timeout=0x28a6e4a8) [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/sync.c:854] in ntdll (0x0000000028a6e458)
1 0x00007feee1d24005 NtWaitForSingleObject+0x38(handle=0xffffffffffffffff, alertable=0, timeout=0x28a6e4a8) [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/sync.c:872] in ntdll (0x0000000028a6e498)
2 0x000000000042a0a1 runtime.usleep2+0x20() in hello (0x000000000881e000) 0x00007feee1d23e82 NtWaitForMultipleObjects+0xd [/home/focht/projects/wine/wine.repo/src/dlls/ntdll/sync.c:854] in ntdll: 854 { --- snip ---
Winedbg isn't useful here because it doesn't support SSE2 instructions. Running winedbg --gdb yields more useful results.
--- snip --- Wine-gdb> disas Dump of assembler code for function NtWaitForMultipleObjects: 0x00007fb720529e75 <+0>: push %rbp 0x00007fb720529e76 <+1>: mov %rsp,%rbp 0x00007fb720529e79 <+4>: push %rdi 0x00007fb720529e7a <+5>: push %rsi 0x00007fb720529e7b <+6>: sub $0x1b0,%rsp => 0x00007fb720529e82 <+13>: movaps %xmm6,-0xb0(%rbp) 0x00007fb720529e89 <+20>: movaps %xmm7,-0xa0(%rbp) 0x00007fb720529e90 <+27>: movaps %xmm8,-0x90(%rbp) 0x00007fb720529e98 <+35>: movaps %xmm9,-0x80(%rbp) 0x00007fb720529e9d <+40>: movaps %xmm10,-0x70(%rbp) 0x00007fb720529ea2 <+45>: movaps %xmm11,-0x60(%rbp) 0x00007fb720529ea7 <+50>: movaps %xmm12,-0x50(%rbp) 0x00007fb720529eac <+55>: movaps %xmm13,-0x40(%rbp) 0x00007fb720529eb1 <+60>: movaps %xmm14,-0x30(%rbp) 0x00007fb720529eb6 <+65>: movaps %xmm15,-0x20(%rbp) --- snip ---
Another case of an app violating the Windows 64-bit ABI.
See bug 27680 and bug 34258 for similar cases.
Before performing the call instruction to 'NtWaitForSingleObject' the stack has to be 16-byte aligned! Hence the caller (= Go runtime) messed this up.
It seems they are already aware of Wine, see: https://code.google.com/p/go/source/browse/src/pkg/runtime/sys_windows_amd64...
The culprit 'usleep2' misaligning the stack through 'ptime' arg:
https://code.google.com/p/go/source/browse/src/pkg/runtime/sys_windows_amd64...
Disassembly:
--- snip --- 0x000000000042a080 runtime.usleep2 in hello: subq $8,%rsp 0x000000000042a084 runtime.usleep2+0x4 in hello: negq %rbx 0x000000000042a087 runtime.usleep2+0x7 in hello: movq %rsp,%r8 0x000000000042a08a runtime.usleep2+0xa in hello: movq %rbx,(%r8) 0x000000000042a08d runtime.usleep2+0xd in hello: movq $0xffffffff,%rcx 0x000000000042a094 runtime.usleep2+0x14 in hello: xorq %rdx,%rdx 0x000000000042a097 runtime.usleep2+0x17 in hello: movq 0x000000000055a970 runtime.NtWaitForSingleObject,%rax 0x000000000042a09f runtime.usleep2+0x1f in hello: calll *%eax 0x000000000042a0a1 runtime.usleep2+0x21 in hello: addq $8,%rsp 0x000000000042a0a5 runtime.usleep2+0x25 in hello: ret --- snip ---
This is not a Wine bug.
Regards
*** This bug has been marked as a duplicate of bug 27680 ***
http://bugs.winehq.org/show_bug.cgi?id=36695
--- Comment #4 from Pietro Gagliardi (andlabs) pietro10@mac.com --- Thanks. I've reported this to the dev team: https://code.google.com/p/go/issues/detail?id=8174
https://bugs.winehq.org/show_bug.cgi?id=36695
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org