A bug in symbol loading in winedbg

[Shachar Shemesh]

Hi all,

Bug Report:
If winedbg is asked to load an external PDB file, and that file does not 
match the executable being run, the debugger does not warn about it. 
Instead, bad things (tm) happen when actually trying to run the executable.

Shachar

[Eric Pouech]

Shachar Shemesh a e'crit :
> Hi all,
>
> Bug Report:
> If winedbg is asked to load an external PDB file, and that file does not 
> match the executable being run, the debugger does not warn about it. 
> Instead, bad things (tm) happen when actually trying to run the executable.
>      Shachar

could you be more specific on the errors ?
- running with +dbghelp
- pasting the output of 'info module'
what are the 'bad things' you're talking about ?

A+

[Shachar Shemesh]

Eric Pouech wrote:
> Shachar Shemesh a e'crit :
> > Hi all,
> >
> > Bug Report:
> > If winedbg is asked to load an external PDB file, and that file does 
> > not match the executable being run, the debugger does not warn about 
> > it. Instead, bad things (tm) happen when actually trying to run the 
> > executable.
> >      Shachar
>
> could you be more specific on the errors ?
> - running with +dbghelp
> - pasting the output of 'info module'
>
> what are the 'bad things' you're talking about ?
>
> A+

I'm sorry - I wrote this email in a hurry, so I don't forget of the 
problem's existance. Will give more details a bit later.

Shachar

[Shachar Shemesh]

Shachar Shemesh wrote:
> Eric Pouech wrote:
> > Shachar Shemesh a e'crit :
> > > Hi all,
> > >
> > > Bug Report:
> > > If winedbg is asked to load an external PDB file, and that file does 
> > > not match the executable being run, the debugger does not warn about 
> > > it. Instead, bad things (tm) happen when actually trying to run the 
> > > executable.
> > >      Shachar
> >
> > could you be more specific on the errors ?
> > - running with +dbghelp
> > - pasting the output of 'info module'
> >
> > what are the 'bad things' you're talking about ?
> >
> > A+
>
> I'm sorry - I wrote this email in a hurry, so I don't forget of the 
> problem's existance. Will give more details a bit later.
>         Shachar

Ok, here goes:
First - reconstruction instructions (Visual Studio 6, latest SP):
Take any C++ project (it happens with the one generated when you ask for 
a sample "hello world" application). Copy the "Release" configuration 
over, and open the project settings. Add to the "C/C++" tab, in the 
"General" section, "Debug info: Program Database". In the "Link" tab, in 
"Debug", check "Debug info", with "Microsoft format". At this point, if 
you compile your project, visual studio's integrated debugger sees the 
debug info, and can debug the application. However, if you try to load 
this very same application in winedbg, it fails to load the symbols. 
Output pasted later on.

Next, go back to the "Link" tab, and add "Separate types". Recompile 
(make sure you "rebuild all"). Now winedbg can see the debug info, and 
works. Before the latest winedbg patch, it worked in the previous mode 
as well.

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".
> 523,524c523,657
> < err:dbghelp_msc:pe_load_debug_directory Got a page fault while 
> loading symbols
> < trace:dbghelp:SymEnumSymbols (0x34 00000000 "*!_WinMain" 0x40768c40 
> 0x4088e110)
> > err:dbghelp_msc:pdb_process_file -Type server .PDB imports ignored!
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1002
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > fixme:dbghelp_msc:codeview_snarf Unsupported id 1013
> > trace:dbghelp:SymGetLineFromAddr 0x34 00401000 (nil) 0x4088db74
>
> 526,527c659,660
> < No symbols found for WinMain
> < Unable to add breakpoint, will check again when a new DLL is loaded
> > Breakpoint 1 at 0x00401000 WinMaintrace:dbghelp:SymGetLineFromAddr
>
> 0x34 00401000 (nil) 0x4088e938
> > [S:\showdebug\showdebug.cpp:24] in showdebug

Let me know if you need any more info.

(obviously, for program listing to actually work, I pointed wine's S: to 
where my sources reside).

Shachar

[Eric Pouech]

> 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)
- 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+

[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)

[Eric Pouech]

Shachar Shemesh a écrit :
> What do you mean by "I don't need to use the S: directory"?

I thought you needed the S: dir for the PDB reading (in fact, you seem 
to, rightfully, only need it for source files)

at least this works here... what's strange anyway in your case is that 
it sometimes crash, and sometimes doesn't. And the gdb info you 
submitted likely shows a stack trashing somewhere.

Index: type.c
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/dlls/dbghelp/type.c,v
retrieving revision 1.5
diff -u -u -r1.5 type.c
--- type.c	24 May 2004 19:08:19 -0000	1.5
+++ type.c	12 Jun 2004 18:56:19 -0000
@@ -238,7 +238,7 @@
      if ((sym = pool_alloc(&module->pool, sizeof(*sym))))
      {
          sym->symt.tag            = SymTagEnum;
-        sym->name = pool_strdup(&module->pool, typename);
+        sym->name = (typename) ? pool_strdup(&module->pool, typename) : 
NULL;
          vector_init(&sym->vchildren, sizeof(struct symt*), 8);
      }
      return sym;

[Shachar Shemesh]

Eric Pouech wrote:
> Shachar Shemesh a écrit :
> > What do you mean by "I don't need to use the S: directory"?
>
> I thought you needed the S: dir for the PDB reading (in fact, you seem 
> to, rightfully, only need it for source files)

Yes. Actually, in the real program, the PDBs are not in the same 
directory as the executable files, and there I also need the mapping for 
them.
> at least this works here... what's strange anyway in your case is that 
> it sometimes crash, and sometimes doesn't. And the gdb info you 
> submitted likely shows a stack trashing somewhere.
> Index: type.c
>
> RCS file: /home/cvs/cvsroot/wine/wine/dlls/dbghelp/type.c,v
> retrieving revision 1.5
> diff -u -u -r1.5 type.c
> --- type.c    24 May 2004 19:08:19 -0000    1.5
> +++ type.c    12 Jun 2004 18:56:19 -0000
> @@ -238,7 +238,7 @@
>      if ((sym = pool_alloc(&module->pool, sizeof(*sym))))
>      {
>          sym->symt.tag            = SymTagEnum;
> -
>    sym->name = pool_strdup(&module->pool, typename);
> -
>    sym->name = (typename) ? pool_strdup(&module->pool, typename) 
>
> : NULL;
>          vector_init(&sym->vchildren, sizeof(struct symt*), 8);
>      }
>      return sym;

Ok, the above patch solves the problem for me. Does that mean we still 
have some stack thrashing somewhere? Could it not be that the "-O2" 
compilation option did the gdb warning?

Is this something valgrind can help with?

Shachar

[Shachar Shemesh]

Shachar Shemesh wrote:
> Ok, the above patch solves the problem for me. Does that mean we still 
> have some stack thrashing somewhere? Could it not be that the "-O2" 
> compilation option did the gdb warning?
>
> Is this something valgrind can help with?
>      Shachar

Hi Eric,

Is there any reason not to submit the two changes (/ -> \ and the other 
one) to wine-patches?

Shachar