Eric Pouech wrote:
Sample session of showdebug/semidebug$ WINEDEBUG=+dbghelp winedbg showdebug.exe Since there is lots of cruft there, I ran it once working and once not, and am only pasting the diff between the two here. Those marked with ">" are the lines when things are working (scroll to the end to verify). The command run was "break WinMain".
there are (at least) two issues:
- the first one is for .pdb files loading. It may well be that if you
change the '/' by a '\' in FindDebugInfoFile in dlls/dbghelp/path.c, you'll get to the files right (no need to use the S: directory)
I've sent you the app off list. It's a really simple one (Visual Studio's "Hello World").
What do you mean by "I don't need to use the S: directory"?
- the second issue is a random crash in PDB/DBG loading
< err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols
which prevent the symbolic info to be loaded, and hence the bp to be set.
The fix for the first item seems easy (if it's what I described above). I'll send later a larger fix for symbol files lookup for dbghelp. The second item seems a bit more trickier (may look like an uninitialized var, but a cursory look at the code didn't shed no light). Knowing where the crash takes place would help. Could you run the debugger in the debugger to get that ? A+
So, we are flaunting off our newfound ability to debug the debugger, eh :) ? Here it is (Right after gdb catches the segmentation fault):
(gdb) bt #0 0x400d5763 in strlen () from /lib/tls/i686/cmov/libc.so.6 #1 0x408b38c5 in pool_strdup (pool=0x40484bb0, str=0x0) at storage.c:134 #2 0x408b72cf in symt_new_enum (module=0x0, typename=0x408bbe7c "\220½\002") at type.c:241 #3 0x00000000 in ?? () #4 0x00000000 in ?? () #5 0x408bbe7c in __JCR_LIST__ () from /home/sun/sources/wine/wine/dlls/dbghelp.dll.so #6 0x40af08c8 in ?? () #7 0x40af08cc in ?? () #8 0x4088da48 in ?? () #9 0x408ab5f8 in codeview_add_type_enum_field_list (module=0x0, typeno=0, list=0x1000 "", len=1078479856) at msc.c:1327 Previous frame inner to this frame (corrupt stack?)
In frame #1, 'pool' is NULL, as is "str". Then again, it may be due to me compiling with -O2, and these vars getting optimized away. In frame #2, typename is still NULL:
(gdb) up #2 0x408b72cf in symt_new_enum (module=0x0, typename=0x408bbe7c "\220½\002") at type.c:241 /home/sun/sources/wine/wine/dlls/dbghelp/type.c:241:9170:beg:0x408b72cf (gdb) print module->pool $1 = {first = 0x0, arena_size = 0} (gdb) print &module->pool $2 = (struct pool *) 0x248 (gdb)