[Bug 39065] New: thread.c, line 403: Crash when attaching debugger (EXC_BAD_ACCESS, EXC_i386_GPFLT)
https://bugs.winehq.org/show_bug.cgi?id=39065
Bug ID: 39065 Summary: thread.c, line 403: Crash when attaching debugger (EXC_BAD_ACCESS, EXC_i386_GPFLT) Product: Wine Version: 1.7.49 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: philippe.groarke@gmail.com
Created attachment 52035 --> https://bugs.winehq.org/attachment.cgi?id=52035 Variables
pthread_join crashes when attaching debugger. This makes it impossible to debug anything. I am using lldb and/or xcode directly. Winedbg also crashes, but I cannot retrieve anything with it.
I attached the state of local variables when it crashes (in exit_thread). I've also attached the variables of call_thread_func and start_thread.
libsystem_pthread.dylib`pthread_join$UNIX2003: 0x9776dedc <+0>: pushl %ebp 0x9776dedd <+1>: movl %esp, %ebp 0x9776dedf <+3>: pushl %ebx 0x9776dee0 <+4>: pushl %edi 0x9776dee1 <+5>: pushl %esi 0x9776dee2 <+6>: subl $0x3c, %esp 0x9776dee5 <+9>: calll 0x9776deea ; <+14> 0x9776deea <+14>: popl %esi 0x9776deeb <+15>: movl 0x8(%ebp), %edi -> 0x9776deee <+18>: movl %gs:0x0, %ebx
Small backtrace: #0 0x9776deee in pthread_join$UNIX2003 () #1 0x7bcb0358 in exit_thread at wine/dlls/ntdll/thread.c:403 #2 0x7bca0b65 in call_thread_func_wrapper () #3 0x7bca3f6b in call_thread_func at wine/dlls/ntdll/signal_i386.c:2732 #4 0x7bca0b22 in call_thread_entry_point () #5 0x7bcb0f6f in start_thread at wine/dlls/ntdll/thread.c:443 #6 0x97769e13 in _pthread_body () #7 0x97769d89 in _pthread_start () #8 0x97767e52 in thread_start ()
Could be many things, open for suggestions.
https://bugs.winehq.org/show_bug.cgi?id=39065
philippe.groarke@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #52035|Variables |exit_thread variables description| |
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #1 from philippe.groarke@gmail.com --- Created attachment 52036 --> https://bugs.winehq.org/attachment.cgi?id=52036 call_thread_func variables
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #2 from philippe.groarke@gmail.com --- Created attachment 52037 --> https://bugs.winehq.org/attachment.cgi?id=52037 start_thread variables
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #3 from Ken Thomases ken@codeweavers.com --- Is this plain Wine? Any hacks or local modifications?
What version of OS X? What version of Xcode and/or lldb?
What are you actually debugging? Show the invocation of that program and of lldb. Exactly what steps would one need to follow to reproduce this, in the simplest case?
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #4 from philippe.groarke@gmail.com --- Plain wine. No hacks (I have 1 modification in wined3d and some more stubs, but this happens on plain wine).
OS X Yosemite 10.10.4, Xcode 6.4, lldb-330.0.48, though this also happens with WineDbg so it doesn't seem to be debugger dependant.
I am debugging Skyforge.
Repro: Launch Skyforge (using the MyComGames.exe launcher). Wait on the skyforge loading screen (don't press spacebar yet).
Attach lldb or winedbg: lldb wine process attach --pid yourpid
(or) Attach through Xcode: Setup a project with external build system, Debug->Attach to process.
In Skyforge press spacebar, crash.
If you attach while it is running, you will also get an instant EXC_BAD_ACCESS, EXC_i386_GPFLT. I've seen the same in glBindFrameBuffer().
https://bugs.winehq.org/show_bug.cgi?id=39065
philippe.groarke@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://static.gc.my.com/Sky | |forgeLoader_en.exe
https://bugs.winehq.org/show_bug.cgi?id=39065
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- (In reply to philippe.groarke from comment #4)
I am debugging Skyforge.
Did you also test with a couple of other applications? Is it only triggered by Skyforge, or also by other apps (for example wine builtin applications like winecfg)?
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #6 from philippe.groarke@gmail.com --- Right now only Skyforge. Winecfg and such aren't really multithreaded (?) so I doubt they spawn and kill many threads during execution. I am currently looking for another similar game/app that doesn't require dll overrides and that is recent/spawns many threads.
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #7 from Sebastian Lackner sebastian@fds-team.de --- Could you check if a log with WINEDEBUG=+seh shows anything useful?
Based on the location where it crashes it sounds like %gs got corrupted somehow. This might be the applications fault, however Wine theoretically has a way to workaround that: http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/signal_i386.c#l1... Is this particular code called, and does the following TRACE appear in the log somewhere?
--- snip --- TRACE( "%04x/%04x at %p, fixing up\n", context->SegGs, system_gs, instr ); --- snip ---
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #8 from philippe.groarke@gmail.com --- Yes I've seen many of those during various debugging/logging scenarios.
ex: 006d:trace:seh:check_invalid_gs 0001/000f at 0x97767f8b, fixing up This is from an older log. Would you like a recent one?
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #9 from Sebastian Lackner sebastian@fds-team.de --- (In reply to philippe.groarke from comment #8)
Yes I've seen many of those during various debugging/logging scenarios.
ex: 006d:trace:seh:check_invalid_gs 0001/000f at 0x97767f8b, fixing up This is from an older log. Would you like a recent one?
Yes, feel free to attach a complete log. It would be interesting to find out why the %gs fixup doesn't happen at the point where it crashes, you could add FIXME's in front of the "return FALSE" instructions in check_invalid_gs() to debug that.
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #10 from philippe.groarke@gmail.com --- Created attachment 52040 --> https://bugs.winehq.org/attachment.cgi?id=52040 log +seh
https://bugs.winehq.org/show_bug.cgi?id=39065
--- Comment #11 from philippe.groarke@gmail.com --- There it is :) So I've added a FIXME to the default case of check_invalid_gs, but it never seems to trigger. The invalid_gs traces start immediately when you launch the game.
https://bugs.winehq.org/show_bug.cgi?id=39065
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
-
wine-bugs＠winehq.org