Multithreaded debugging
Peter Urbanec
winehq.org at urbanec.net
Mon Nov 9 23:30:03 CST 2009
Eric Pouech wrote:
> Peter Urbanec a écrit :
>> It can't be as simple as updating the value of dbg_curr_thread with
>> the result of dbg_get_thread(dbg_curr_process, tid) and then calling
>> GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it?
>>
> the changes will need to be larger than that
> winedbg assumes throughout the code that it's stopped in a single thread
> but, if you change dbg_curr_thread, and enter the 'cont' command, you
> have to decide which thread should be resumed
> therefore, the changes imply to use two different objects:
> - the thread on which an exception occured
> - the thread you're currently examining
> and that's not a simple task
> moreover it'll be hard to understand the difference between the two
> above mentionned thread objects
>
> so, finding another solution might be preferable
> what are the thread's missing information you were thinking of ?
I would like to do the following:
[ exception / attach to process ]
[ all threads in process are now suspended ]
info threads
thread 0x42
bt
info locals
print *some_class
up
info locals
print *some_var
Or in other words, being able to examine the state of any thread,
including the state of local variables in various stack frames, would be
invaluable in determining how various threads got to where they are and
what they are doing.
Obviously, the above example is only workable if all threads in the
debugged process are suspended. If only the current thread is suspended,
it makes it very difficult to debug multithreaded code anyway.
Controlling execution of individual threads with cont is not very
important to me. I'd be quite happy for the debugger to stop and start
all threads in a process together.
The application that I am working with routinely has around 20-30
threads in interactive use and the thread count goes even higher when
rendering jobs are started.
Best regards,
Peter Urbanec
More information about the wine-devel
mailing list