A bug in symbol loading in winedbg

[Shachar Shemesh]

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)


-- 
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/