Winedbg
From Wine-Wiki
Contents
|
WineDbg
This is not advice or official documentation. This is a compilation of comments from the mailing lists and comments by wiki users. If you spot an error or mistake, because this is a wiki, you are invited to fix it.
Official Documents are available on the Wine site:
GUI
Using Eclipse
M. Ost [Feb 06] posted about how to get debugging working with eclipse in fedora 4: Eclipse is version 3.1.1 updated from the eclipse UI from the version that came with FC4 [using yum update]. wine archive
In regedit:
- disabled auto winedbg by renaming AeDebug
- I changed HKEY_LOCAL_MACHINE/Software/Microsoft/Windows
- NT/Current Version/AeDebug to AeDebug-DISABLED. Without this gdb doesn't seem to be able to get a hold of SEGFAULTs.
In eclipse's Run/Debug dialog box:
- set the c/c application to WINE_SRC/loader/wine-pthread
- WINE_SRC points to a compiled version of wine. For me, I got the wine src rpm and ran rpmbuild -bb. This is where main() is, which eclipse looks for at start up.
- put your .exe.so file on the Arguments tab
- choose the GDB Debugger on the Debugger tab
- add WINE_SRC on the Source tab as a "Filesystem directory with
subdirectories"
The only weirdness so far is that sometimes (not always) the debugger suspends when a new thread is created. I just resume (F8) past that. And I am not sure what impact bypassing wine-preload's exec-shield workaround will have on me. [...] But I gotta say that having a functioning IDE with integrated debugging on Linux is a major relief [...]
kdbg
Feb 2008 a developer asked about kdbg (Graphical kde debugger)
E. Pouech replied: winedbg works, winedbg --gdb works, kdbg works as well (look at the tips on the wine doc about setting up kdbg with winedbg and the gdb proxy...). it however requires a patch for the proxy that i'm about to send for newer gdb versions
A user asked [Nov 2005] about ddd or kdbg. E. Pouch gave some pointers with kdbg that have yet to be added to the official doc's [Oct 05]: For kdbg, it works fine (except I get some quirks here):
- be sure the specify on kdbg command line the wine real executable you're using (either wine-pthread or wine-kthread)
- in kdbg, strangely enough the "Continue" item Execute menu doesn't work (IMO, it's a bug in kdbg as it's translated as a "run" command, while for a remote target it should be a 'continue' command).
- hence, I suggest to set a breakpoint on pgm entry point (either WinMain or main), which isn't it at that time of execution, and then use solely the Execute item (F5)
- in my case, the source code doesn't show up alone. I use the 'show code' button in the breakpoint window Wine Archive
PE and ELF
A user asked tried to install explorer (not internet explorer): When the debugger started, they typed bt, to get a backtrace:
Backtrace: =>1 0x40195be8 stub_entry_point 0x58(dll=0x103be9c, name=0x2d3) [loader.c:186] in ntdll (0x4068fe54) fixme:dbghelp:sffip_cb NIY on 'explorer.pdb' 2 0x01014145 in explorer ( 0x14145) (0x4068fe80) 3 0x0101233e in explorer ( 0x1233e) (0x4068febc) 4 0x01016132 EntryPoint 0x66 in explorer (0x4068ff20) 5 0x404e63c2 start_process 0xf2(arg=0x0) [/root/wine-svn-troy/wine/trunk/dlls/kernel/process.c:996] in kernel32 (0x4068fff4) 6 0x40038fe1 wine_switch_to_stack 0x11 in libwine.so.1 (0x00000000) 0x40195be8 stub_entry_point 0x58 [loader.c:186] in ntdll: subl $4,%esp Unable to open file 'loader.c' Modules: Module Address Debug info Name (59 modules) PE 0x01000000-010f8000 Export explorer ELF 0x40000000-40017000 Deferred ld-linux.so.2 ELF 0x40034000-4004d000 DIA libwine.so.1 ELF 0x4004d000-4015a000 Deferred libc.so.6 ELF 0x4015a000-4015d000 Deferred libdl.so.2 ELF 0x4015d000-401d9000 Stabs ntdll<elf> \-PE 0x40180000-401d9000 \ ntdll ELF 0x401f5000-402ea000 Deferred libwine_unicode.so.1 [...] ELF 0x40735000-407c4000 Deferred gdi32<elf> \-PE 0x40750000-407c4000 \ gdi32 ELF 0x407c4000-408f6000 Deferred user32<elf> \-PE 0x407f0000-408f6000 \ user32 ELF 0x40910000-409db000 Deferred shell32<elf> They asked: what does this line from the debugger mean?: ELF 0x40910000-409db000 Deferred shell32<elf> \-PE 0x40930000-409db000 \ shell32
U. Bonnes: Did you use native shell (PE) or builtin (elf)?[...] The debugger gives the range where builtin shell32 was loaded, or probably is to be loaded on demand (deferred). Wine Archive
Is it now possible to, also see PE (.pdb) debugging info?
E. Pouch [Nov 05]. This would require gdb to know about .pdb, which it doesn't. in the long run, it may be easier to get windbg handle properly elf/{stabs|dwarf} information, rather than the other way around.
Dwarf2 Support
Currently [May 05] Wine is built with the gstabs option. Work has been progressing on WineDgb and Dwarf2. Raphael: We only have to build a correct symt model to get it working perfectly.
L. Ulmer wrote: This will allow to build Wine without the -gstabs compilation flag. Ie Wine will understand the new (standard) DWARF2 debugging symbols.
E. Pouch: At the moment backtraces already give function information... it will display information for ELF modules with Dwarf2 debug info (instead of the STABS format) this will raise some day the question of which debug format we use for Wine's own use
Raphael: dwarf2 debug format is the standard format since gcc3 (and dwarf3 format which is an dwarf2 extension, is already specified so gcc4/5 may use it). Stabs format (used when -gstabs option is specified) are only supported (without any evolution) for backward compatibility with olders debuggers. If you want to get maximum debug infos [with] recent gccs' you must use dwarf2 (and prepare [for the] future when stabs format [will no longer be] supported)Wine Archives
Further Reading
Debugger Startup
A programmer asked [July 05]: To implement a Solaris debugger I have traced the wineservers startup and there is something I don't understand. I get the following stack trace:
>send_thread_signal 0x4a(80aab90, 10) >stop_thread 0x1f(80aab90) >suspend_process 0x4d(81c72a8) >debugger_attach 0xf1(81c72a8, 81d1b58) >req_debug_process 0x4c(81d1c38, 80477a0) >call_req_handler 0x74(81d1b58) >read_request 0x68(81d1b58) >thread_poll_event 0x62(81d22b0, 1) >fd_poll_event 0x14(81d22b0, 1) >main_loop 0x9e(804785c, 8056a51, 1, 8047868, 8047870, 804785c) >main 0xc6(1, 8047868, 8047870) >_start 0x5d(1, 804795c, 0, 8047979, 80479f6, 8047a0a)
debugger_attach calls suspend_process then stop_thread, stop_thread sends a SIGUSR1 at the thread of interest. The result of this is that the thread is terminated and there is nothing to attach to....
Why is this SIGUSR1 sent ?
R. Shearman: It is the way suspending processes is done because the kernel doesn't allow us to do it. The handler should be installed in the file dlls/ntdll/signal_i386.c. You probably want to find out why it isn't being installed correctly. Wine Archive
The programmer asked: Why not just write a SIGSTOP?
M. Hearn: SIGSTOP has process scope on NPTL, I think. If SIGUSR1 isn't handled, then stuff will break mysteriously. Essentially all it does is block on a wineserver fd until the thread is woken up again. In future it'll also store the sigcontext so copy protection and such works.
Setting Breakpoints
A programmer said [Jun 06]: I am trying to get classic Myst to run again under wine. How do I set a breakpoint in it when it run by winevdm.
E. Pouch the answer depends on several aspects: - setting a breakpoint on wine code: that should work wine (especially for all DLLs, 16 or 32 bit) - setting a breakpoint in Myst code. Since it runs in winevdm, I assume it's a 16 bit exec. Symbolic information and other advanced debugging stuff (DLL loading event...) is not supported. The only thing you can do is set a breakpoint by address. It should work when expressed as a segmented address (bp 0x1234:0x5678). wine archive
A programmer asked [Oct 05]: How do you set breakpoints in 16 bit code [...] I can add in the winedos code a debugbreak at a particular point in time, and I really want to step through some of the code following the return to see why something is happening.
If I do, for example, break 0x1257:0x33f3 or *0x1257:0x33f3 it doesn't work.
E. Pouch: No, that's currently broken [Oct 05]. You could try to do:
info seg 0x1257
get the base of the segment, add 0x33f3 to it, and set the bp by hand at the linear address (b * <result>)
Deferencing a Pointer
A programmer queried [Nov 05] Is it possible to dereference a pointer in winedbg? [...] $eax is the pointer to a code pointer. [The Help files] say that
- "*$eax"
is a valid expression. But [I get the error] No type or type mismatch when I'm trying to use it it saying: wine archive
- Wine-dbg>p *$eax
M. Meissner: x aka examine memory
- x $eax
The programmer clarified: Well I need to add that to display. Something like: display/x *$eax Doing x $eax and then x <result> 100s times kind of hard.
E. Pouch: display /x means (in gdb) formatting differently the output, not dereferencing the (so called) pointer (display is a repeated 'p' command, not a 'x' one). what you'd need is support for type casts and use something like:
- display *(int*)$eax
I sent a couple of months ago a patch for winedbg that (partly) implemented the support for typecasts in wine. (not sure it still applies cleanly, at least some tiny parts are now in CVS tree) http://www.winehq.org/hypermail/wine-devel/2005/03/0219.html
wine_debug_set_channel_flags
A programmer asked: wine_dbg_parse_options does not exist anymore. Is there any other way to enable debug channels from whithin wine code ?
A. Juliard [Oct 05]: I just added a __wine_dbg_set_channel_flags function. Note that because of the way the new channel handling works, the channel needs to be specified in the WINEDEBUG options to allow the flags to be changed dynamically. [...] you have to specify channels explicitly (and they need to be channels that were part of the WINEDEBUG setting). We no longer maintain a global list of channel variables so there's no way to set them all. Wine Archive
Troubleshooting Winedbg
A developer wrote [Feb 08 wine devel]:I've have setup my debug build (with pdbs) and MSVCRT debug dlls.When stopping on a breakpoint with winedbg, I get a stack of calls in winedbg which does not contains any function info from my dlls or app. I only get hex offset of call within my dll. But I do see the information for wine sources though, function name + line number. What do I need to do so that winedbg can extract info from my pdb?
E. Pouech : _NT_SYMBOL_PATH env variable should point to where your pdb files are
Another developer wrote: I am trying to use gdb for debugging. I run the command:
- winedbg --gdb sol.exe
I then get the following output: WineDbg starting on pid 0xa
fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for wine-pthread fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for ntdll<elf> fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 [...]fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for uxtheme<elf> 0x7eecaf5a start_process 0xde in kernel32:[...]
I don't end up with a gdb prompt. It is just stuck there. I am following: http://www.winehq.com/site/docs/winedev-guide/dbg-others [...] Running without gdb ('winedbg sol.exe') works fine.
E. Pouech: yeah, that's a bug. I'm working on it [... and shortly afterward he posted] it should be fixed in current CVS. wine archive
WineDbg Troubleshooting
Initiating DbgHelp
WineDbg starting on pid 0xa
Couldn't initiate DbgHelp [1]
Couldn't initiate DbgHelp is the important line.
The only reason this fails is because dbghelp cannot get to the wine-loader in the running program. try to set the env var WINELOADER to the {pk}loader (full path) you're using and check again.
fixme:dbghelp:elf_load_debug_info_from_map Unsupported Dwarf2information for testapib<elf>
Backtrace: =>1 0x00000000 (0x406efe60) fixme:dbghelp:elf_load_debug_info_from_map Unsupported Dwarf2information for testapib<elf> 2 0x405e5276 WinMain in testapib (0x406efe90) 3 0x405e5173 __wine_exe_main in testapib (0x406eff20) 4 0x404e0de2 in kernel32 ( 0x50de2) (0x406efff4) 5 0x4001d181 wine_switch_to_stack in libwine.so.1 (0x00000000) 0x00000000: addb[...]
R. Shearman:Compile your program with the "-gstabs " flag and you will get debugging information compatible with winedbg. From there, it should be easier to work out the real cause of the crash. Wine Archive Link
If I try to GDB wine I get all sorts of ugly errors
A User wrote: If I try to GDB wine I get all sorts of ugly errors
M. Hearn: Strace is a relay trace for the kernel. Try an strace in "follow forks mode". Does that help? Wine Archive Link
- WINEDEBUG= relay strace -f wine
The user reported: I also happened to be tailing the syslog (I was looking at something completely different) and I noticed that the following was written:
May 11 22:50:55 orac kernel: strace[7749] trap stack segment rip:410c86 rsp:800000007b20 error:0 May 11 22:50:55 orac kernel: wine-preloader[7750]: segfault at 000000005575b624 rip 000000005575b624 rsp 00000000ffffc824 error 15
M. Hearn:Somehow you managed to compile Wine as 64-bits, which isn't going to work [yet]. I think you need to remove your current Wine installation and install/compile it as 32 bits.
Using Visual Studio
A programmer wrote that there were problems [Feb 2008 wine devel] with Visual Source 2005 and winedbg. A developer suggested: can you try this patch: http://www.winehq.org/pipermail/wine-patches/2008-January/049156.html However E. Pouech commented: as explained earlier, this patch is mostly wrong on lots of aspects I do have partial solution to it, but it's not finished yet
A User posted for assistance with debugging a problem with his application running on Wine using Visual Studio to debug remotely.
Wine Expert, E. Pouech described the process:
- kernel send a trap signal - wine's ntdll catches it, and queue the information as a debug event in the wineserver - the debugger (msvcmon in your case) get notified of the trap while waiting for a debug event
after further discussion, E. Pouech May 05: what's strange is that esp is within stack limit... wine exception handler must see this from another part... it may come from msvcmon tweaking the selectors (cs, ss) for some reasons. He then asked for a Winedebug trace: Wine Archive thread Link
seh, server
Troubleshooting winedbg and MFC42 symbols
A programmer noted [Feb 06]: winedbg [has trouble with] the MFC42 symbols. For example, by disassembling from the load address of MFC42 I was able to identify the CString::FreeData() function at 0x5f402125, but winedbg tells me it's 0x5f445900. Is this a known problem? I have:
- /home/[redacted]/.wine/drive_c/windows/system/MFC42.DLL
- /home/[redacted].wine/drive_c/hager/Semiolog/Apps/MFC42.MAP
- /home/[redacted].wine/drive_c/hager/Semiolog/Apps/MFC42.PDB
I have copied those DLL's off a VC 6.0 CD: MFC42.DLL from OS\SYSTEM into windows/system MFC42.MAP MFC42.PDB from VC98\DEBUG into the directory I run the application from. wine archive
E. Pouech noted the trace showed a different path: yes, when you have several versions of MFC42.PDB like you seem to do (we don't lookup up for the right one yet). [...]also, we don't check (yet) CRC when loading PDB, which may also be the issue. [The discussion ended soon after without any significant resolution]
Troubleshooting Unknown stab Debug Output
A User reported [May 05]: Whenever wine crashes, I get a long stream of unknown stab types.[...] After a couple parts of the bt, the error message files a couple hundred lines, then another couple lines of the bt, so I can't see the whole bt at once. Sometimes parts of the bt are scrolled up past my history limit. He posted some of the output:
err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e err:dbghelp_stabs:stabs_parse Unknown stab type 0x4e err:dbghelp_stabs:stabs_parse Unknown stab type 0x2e [...]
E. Pouech: those stabs types seem to be emitted only on darwin. Anyway, that's easy to silence them since they're not documented in standard ELF format.
H. Leidekker: Some googling turned up N_BNSYM for 0x2e and N_ENSYM for 0x4e. Does that ring a bell?
E. Pouech: those seem only created for darwin from what I can see IMO, we should:
- define the N_{BE}NSYM as any other stabs type
- group them together in the case switch (they are paired anyway)
- and add a comment to explain what it is
Shortly aftwarward on Wine CVS: Modified files:dlls/dbghelp : stabs.c
H. Leidekker: Silence some unknown stab type messages.
Troubleshooting Debugging Wine in the source tree (eg. not with wine installed)
wine: Unhandled exception (thread 0009), starting debugger... err:winedbg:main Invalid event handle: 0x100
[Oct 05] I run wine not installed, e.g. I start wine with the fully qualified path and also the Aedebug registry entry contains the full path.
A. Julliard: That's most likely the problem, if you specify the path to the winedbg wrapper script it gets launched as a Unix process, and doesn't inherit handles. Simply use 'winedbg' in the AeDebug entry, it should work fine when running from the source tree too.
E. Pouch: I suppose it's a vanilla Wine tree... what happens is that the event used to synchronize with the debugger is
not valid in the debugger what happens is that the event doesn't exist (or no longer exist) when the debugger starts. this can happen if either the crashing program died at some point... where does in your log process 8 terminate ? The debuggee is made of threads 9,a,b (and the debugger as a pid c and its main thread is d), and is still running when the event is set by the debugger.
The programmer asked: Will wine now start the installed winedbg in the path or the winedbg from the path where wine was started from?
A. Julliard: The first one it finds in WINEDLLPATH, which should be in the source tree if you are using the standard wine wrapper script.
the debugger doesn't find the source
A programmer noted: starting AvrStudio from the wine debugger on my non-installed wine setup, the debugger doesn't find the source:
/home/wine/wine/programs/winedbg/winedbg AvrStudio4/AVRStudio.exe [...] fixme:msxml:domdoc_createNode First chance exception: page fault on read access to 0x00000000 in 32-bit code (0x7a64736c). Register dump: [...] Stack dump: [...] Backtrace: =>1 0x7a64736c domdoc_appendChild(iface=0x7bcb7278, newChild=0xb7fa7d17,outNewChild=0x0) [domdoc.c:290] in msxml3 (0x7baaf390) 2 0x00405052 in avrstudio ( 0x5052) (0x7bd1c1a4) 3 0x006c0065 (0x7bc10000) 0x7a64736c domdoc_appendChild 0xc [domdoc.c:290] in msxml3: movl[...] Unable to open file 'domdoc.c'
E. Pouch: [Oct 05] where are you running wine from ? top of the CVS tree ? there are a couple of bugs related to this all source finding in current winedbg:
- you cannot setup a dir where to lookup for file (nor does winedbg try some nice spots)
- you should be able to enter the name of the directory to lookup, but some internal flags are not set up at the right time Wine Archive
