[Bug 36695] 64-bit binaries produced by Go compiler for windows/amd64 target crash (stack pointer (RSP) must be 16-byte aligned when making a call to Win64 API)
wine-bugs at winehq.org
wine-bugs at winehq.org
Sun Jun 8 14:34:53 CDT 2014
http://bugs.winehq.org/show_bug.cgi?id=36695
Anastasius Focht <focht at 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 at 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.s#317
The culprit 'usleep2' misaligning the stack through 'ptime' arg:
https://code.google.com/p/go/source/browse/src/pkg/runtime/sys_windows_amd64.s#362
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 ***
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
More information about the wine-bugs
mailing list