http://bugs.winehq.org/show_bug.cgi?id=20617
Summary: Multithreaded crashing programs create misleading backtraces when winedbg --auto is called Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winedbg AssignedTo: wine-bugs@winehq.org ReportedBy: bugzilla.winehq.org@urbanec.net
Created an attachment (id=24590) --> (http://bugs.winehq.org/attachment.cgi?id=24590) MultipleThreads test case executable - requires Zoo.dll
When a multithreaded program crashes and winedbg --auto is called to generate a back trace, the result is not always a back trace for the thread that caused the crash in the first place.
The attached files can be used to reproduce this problem. The program MultipleThreads.exe takes no arguments and creates three new threads, each with a data structure that contains a timeout variable set to 200ms and the thread start function is set to a function in Zoo.dll. The main thread also calls the same function in Zoo.dll with the timeout variable set to 240ms.
The function in Zoo.dll prints the value of the timeout, then sleeps for the duration of the timeout. After this, the function prints that it will crash, then causes an exception by a write to 0x00000000.
When I run this program, the output is non-deterministic, but more often than not, the reported crashing thread does not match the thread which is shown in the backtrace. The discrepancy can be seen from this output:
Thread 0x0019 *** C R A S H I N G *** wine: Unhandled page fault on write access to 0x00000000 at address 0x10001123 (thread 0019), starting debugger... Thread 0x001a *** C R A S H I N G *** Thread 0x001b *** C R A S H I N G *** Thread 0x0009 *** C R A S H I N G *** Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x10001123). ... [Register, and stack dumps, backtrace, module list] ... Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\tmp\WineCrashTest\MultipleThreads.exe 0000001b -2 0000001a -2 <== 00000019 -2 00000009 -2
Notice how the first thread to report crash intent was 0x0019, which matches the the page fault reported by except.c:start_debugger(). However, the thread list generated by winedbg shows the current thread to be 0x001a.
Also notice that even though the crashing process invoked the debugger on exception in thread 0x0019, the other three threads in the crashing process continued to run and generated further page faults before the debugger started.
I would expect that when a crash occurs, all threads in the process would be suspended immediately and the debugger would be able to determine the thread that caused the exception.