[Bug 20617] New: Multithreaded crashing programs create misleading backtraces when winedbg --auto is called

[wine-bugs at winehq.org]

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 at winehq.org
        ReportedBy: bugzilla.winehq.org at 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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.