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.
http://bugs.winehq.org/show_bug.cgi?id=20617
--- Comment #1 from Peter Urbanec bugzilla.winehq.org@urbanec.net 2009-11-08 08:34:05 --- Created an attachment (id=24591) --> (http://bugs.winehq.org/attachment.cgi?id=24591) Zoo.dll library with crash functions - required by MultipleThreads.exe
http://bugs.winehq.org/show_bug.cgi?id=20617
--- Comment #2 from Vitaliy Margolen vitaliy@kievinfo.com 2009-11-08 11:16:51 --- Can you make it a plan C test case?
http://bugs.winehq.org/show_bug.cgi?id=20617
Peter Urbanec bugzilla.winehq.org@urbanec.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24590|0 |1 is obsolete| |
--- Comment #3 from Peter Urbanec bugzilla.winehq.org@urbanec.net 2009-11-08 17:54:28 --- Created an attachment (id=24607) --> (http://bugs.winehq.org/attachment.cgi?id=24607) MultipleThreads test case executable - simplified standalone version.
I've simplified the test case code and it now consists of a standalone executable built from a single source file.
The backtrace output from this version will be slightly different, but the issue still remains.
I am providing an executable with this attachment and the corresponding source code in the next one.
http://bugs.winehq.org/show_bug.cgi?id=20617
Peter Urbanec bugzilla.winehq.org@urbanec.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #24591|0 |1 is obsolete| |
--- Comment #4 from Peter Urbanec bugzilla.winehq.org@urbanec.net 2009-11-08 17:56:01 --- Created an attachment (id=24608) --> (http://bugs.winehq.org/attachment.cgi?id=24608) MultipleThreads test case source code
http://bugs.winehq.org/show_bug.cgi?id=20617
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase
http://bugs.winehq.org/show_bug.cgi?id=20617
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |nerv@dawncrow.de Ever Confirmed|0 |1
--- Comment #5 from André H. nerv@dawncrow.de 2009-11-09 14:24:30 --- confirming you really should make a pure c test out of it. for the moment its also possible to make a winelib-app out of the cpp-file just store it in some empty folder and run "winemaker ." in it. then run make
http://bugs.winehq.org/show_bug.cgi?id=20617
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #6 from Bruno Jesus 00cpxxx@gmail.com 2012-05-12 22:23:12 CDT --- Still present in wine 1.5.4.
https://bugs.winehq.org/show_bug.cgi?id=20617
--- Comment #7 from Austin English austinenglish@gmail.com --- Still in wine-1.7.23-33-gc654b7b.
https://bugs.winehq.org/show_bug.cgi?id=20617
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #8 from joaopa jeremielapuree@yahoo.fr --- Looks like the bug is fixed in wine-7.9-rc5:
wine MultipleThreads.exe Thread 0x0120 sleeping 240ms Thread 0x0120 sleeping 240ms Thread 0x012c sleeping 200ms Thread 0x0120 sleeping 240ms Thread 0x012c sleeping 200ms Thread 0x0130 sleeping 200ms Thread 0x0120 sleeping 240ms Thread 0x012c sleeping 200ms Thread 0x0130 sleeping 200ms Thread 0x0134 sleeping 200ms Thread 0x012c *** C R A S H I N G *** Thread 0x012c *** C R A S H I N G *** Thread 0x0134 *** C R A S H I N G *** Thread 0x012c *** C R A S H I N G *** Thread 0x0134 *** C R A S H I N G *** Thread 0x0130 *** C R A S H I N G *** wine: Unhandled page fault on write access to 00000000 at address 0040105B (thread 012c), starting debugger... Thread 0x0120 *** C R A S H I N G *** Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x0040105b). 013c:fixme:dbghelp_dwarf:dwarf2_read_range no entry found Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:0040105b ESP:00d9ff28 EBP:00d9ff30 EFLAGS:00010206( R- -- I - -P- ) EAX:0021fe3c EBX:0021fe3c ECX:00000000 EDX:00000075 ESI:00000000 EDI:00000000 Stack dump: 0x00d9ff28: 0021fe3c 00000130 00d9ff48 7b62df20 0x00d9ff38: 0021fe3c 7bc57be7 7bc57be7 0021fe3c 0x00d9ff48: 00d9ff5c 7bc57be7 0021fe3c 00000000 0x00d9ff58: 00000000 00d9ffec 7bc582a0 7b62df10 0x00d9ff68: 00401000 0021fe3c 00000000 00000000 0x00d9ff78: 00000000 00000000 00000000 00000000 Backtrace: =>0 0x0040105b in multiplethreads (+0x105b) (0x00d9ff30) 1 0x7b62df20 WriteTapemark+0x100(device=0021FE3C, type=<is not available>, count=<is not available>, immediate=<is not available>) [Z:\usr\src\packages\BUI LD\dlls\kernel32\tape.c:317] in kernel32 (0x00d9ff48) 2 0x7bc57be7 RtlWakeConditionVariable+0x57(variable=7B62DF10) [Z:\usr\src\packages\BUILD\dlls\ntdll\sync.c:766] in ntdll (0x00d9ff5c) 3 0x7bc582a0 RtlCreateUserThread(entry=00401000, arg=0021FE3C) [Z:\usr\src\packages\BUILD\dlls\ntdll\thread.c:261] in ntdll (0x00d9ffec) 0x0040105b multiplethreads+0x105b: movl %ecx,0x00000000 Modules: Module Address Debug info Name (5 modules) PE 00400000-0040b000 Export multiplethreads PE 70b40000-70e17000 Deferred ucrtbase PE 7b000000-7b342000 Deferred kernelbase PE 7b600000-7b924000 Dwarf-4 kernel32 PE 7bc00000-7be8b000 Dwarf-4 ntdll Threads: process tid prio (all id:s are in hex)
0000011c (D) Z:\home\wine\TÚlÚchargements\MultipleThreads.exe 00000120 -2 0000012c -2 00000130 -2 <== 00000134 -2 00000140 0 00000124 conhost.exe
https://bugs.winehq.org/show_bug.cgi?id=20617
--- Comment #9 from Peter Urbanec bugzilla.winehq.org@urbanec.net --- The sample output you posted does not look fixed at all. The crashing thread reported by the debugger does not match the output near the end.