http://bugs.winehq.org/show_bug.cgi?id=7560
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #3 from Anastasius Focht focht@gmx.net 2007-11-23 11:45:05 --- Hello,
well I came back here while browsing appdb for interesting stuff.
--- quote --- you confirm that it hangs when you try to trace multithreaded programs? --- quote ---
No, tracing works for multithreaded programs.
--- quote --- When the pause function is used the disassembly window goes blank and can not be used until the process is restarted. The same thing happens when you attach to an already running process, and when an application exits. ... It's only when the pause function itself is explicitly activated that the disassembly window goes blank. --- quote ---
This is expected behaviour. The debugger hits wine code in builtins outside of PE section/win32 API virtual mapping range which leads to empty code/disassembly window (example: PIC load code on function entry) Look at registers window while you step, you can see EIP changing but no code is actually displayed. Just hit a few "run until return" until the code reaches PE range again. Then the code/disassembly will reappear.
--- quote --- When applications are first loaded in to debugger, there are usually lots of "Unable to open or read executable file FOO.dll" and "Bad or unknown format BAR.dll" errors for dozens of DLLs and maybe one or two .drv files. .. --- quote ---
Expected behaviour. The debugger stumbles over wine builtins.
Version 2.0 of the debugger seems to handle things better. But it's in early development stage and has much functionality missing from 1.1
I'd say close this bug. In general debugging multithreaded works, though with some limitations. Not being able to display thread user/kernel times is not a blocker. The other issues related to wine builtins cannot be fixed due to wine design (not a blocker).
Regards
-
wine-bugs＠winehq.org