[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(a)winehq.org Reporter: philippe.groarke(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 philippe.groarke(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #52035|Variables |exit_thread variables description| | -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #1 from philippe.groarke(a)gmail.com --- Created attachment 52036 --> https://bugs.winehq.org/attachment.cgi?id=52036 call_thread_func variables -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #2 from philippe.groarke(a)gmail.com --- Created attachment 52037 --> https://bugs.winehq.org/attachment.cgi?id=52037 start_thread variables -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #3 from Ken Thomases <ken(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #4 from philippe.groarke(a)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(). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 philippe.groarke(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://static.gc.my.com/Sky | |forgeLoader_en.exe -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #5 from Sebastian Lackner <sebastian(a)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)? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #6 from philippe.groarke(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #7 from Sebastian Lackner <sebastian(a)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 --- -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #8 from philippe.groarke(a)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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #9 from Sebastian Lackner <sebastian(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #10 from philippe.groarke(a)gmail.com --- Created attachment 52040 --> https://bugs.winehq.org/attachment.cgi?id=52040 log +seh -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 --- Comment #11 from philippe.groarke(a)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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=39065 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- 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.
participants (1)
-
wine-bugs＠winehq.org