Susan asked:
[What can you do to get a backtrace of a hung app that won't hang when you run it in winedbg?]
I ran into this last week and added a note to
http://wiki.winehq.org/Backtraces
"Alternately, instad of info process / attach, you can do 'bt all' to get backtraces of all threads in all running processes. This is handy when debugging hangs."
That's not a very clear explanation, but what it means is: start winedbg without any app say 'bt all' in winedbg Voila, you now have backtraces for every process, including the hung one. It's your job to get that into a text file and remove the uninteresting ones...
Dan Kegel wrote:
start winedbg without any app say 'bt all' in winedbg Voila, you now have backtraces for every process, including the hung one. It's your job to get that into a text file and remove the uninteresting ones...
I've also been trying to debug a multithreaded app. There are at least two complications that winedbg throws up:
1. Is now documented in http://bugs.winehq.org/show_bug.cgi?id=20617
2. As far as I can tell, winedbg will not allow you to switch the current thread context. This means that even though you can get a backtrace of all threads in all processes, you actually can not examine the state of a specific thread.
I don't know enough about the internals of wine to go ahead and implement a "thread tid" command. I could manage the code in dbg.y and debug.l to implement the command line interface. When it comes to the actual implementation, I can sort of guess at what may need to be done there. However, I suspect that my naive attempts at an implementation are unlikely to produce an acceptable patch.
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?
Peter Urbanec a écrit :
Dan Kegel wrote:
start winedbg without any app say 'bt all' in winedbg Voila, you now have backtraces for every process, including the hung one. It's your job to get that into a text file and remove the uninteresting ones...
I've also been trying to debug a multithreaded app. There are at least two complications that winedbg throws up:
Is now documented in http://bugs.winehq.org/show_bug.cgi?id=20617
As far as I can tell, winedbg will not allow you to switch the
current thread context. This means that even though you can get a backtrace of all threads in all processes, you actually can not examine the state of a specific thread.
I don't know enough about the internals of wine to go ahead and implement a "thread tid" command. I could manage the code in dbg.y and debug.l to implement the command line interface. When it comes to the actual implementation, I can sort of guess at what may need to be done there. However, I suspect that my naive attempts at an implementation are unlikely to produce an acceptable patch.
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 ?
A+
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
-
Dan Kegel -
Eric Pouech -
Peter Urbanec