Missing file names in WINEDBG

[lats]

In the last week WINEDBG has stopped outputting the file/path and 
linenumber of entries in the backtrace.  Does anyone know what happened?

Jeff

[Eric Pouech]

lats a écrit :
> In the last week WINEDBG has stopped outputting the file/path and 
> linenumber of entries in the backtrace.  Does anyone know what happened?

Do you mean that either:
1/ backtraces (for a given program, in a given situation) used to provide file & line number
2/ some (random) backtraces you've seen recently don't provide file & line number

If the later, that's normal (in some cases). For addresses (in a bt) for which we don't find a function, we just print the name 
of the module and the offset from the start of the module, but no file & line number (since we don't have a function)
If the former, that's not normal. What does the attached patch do ?
A+

Index: memory.c
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/programs/winedbg/memory.c,v
retrieving revision 1.13
diff -u -u -r1.13 memory.c
--- memory.c	8 Nov 2004 20:25:55 -0000	1.13
+++ memory.c	13 Nov 2004 15:05:31 -0000
@@ -552,7 +552,7 @@
      /* grab module where symbol is. If we don't have a module, we cannot print more */
      im.SizeOfStruct = sizeof(im);
      if (!SymGetModuleInfo(dbg_curr_process->handle, isf.InstructionOffset, &im))
-        return;
+        strcmp(im.ModuleName, "<--NoModule-->");

si->SizeOfStruct = sizeof(*si);
      si->MaxNameLen   = 256;

[jeffl]

Eric, it is number one.

Eg:
> 1 0x40912b8f GDI_GetObjPtr+0x197(handle=0x107f, magic=0xffff) 
> [/winf/dlls/gdi/gdiobj.c:861] in gdi32 (0x4073fcac)
>   2 0x40912c71 DeleteObject+0x39(obj=0x107f) 
> [/winf/dlls/gdi/gdiobj.c:919] in gdi32 (0x4073fccc)

as it was last week and
> 3 0x40915afd GDI_GetObjPtr+0x105 in gdi32 (0x4073fcac)
>   4 0x40915c35 DeleteObject+0x39 in gdi32 (0x4073fccc)

as it was after the last CVS update.  I assume that there has been a 
config change that has turned off debugging info.

Jeff

Eric Pouech wrote:
> lats a écrit :
> > In the last week WINEDBG has stopped outputting the file/path and 
> > linenumber of entries in the backtrace.  Does anyone know what happened?
>
> Do you mean that either:
> 1/ backtraces (for a given program, in a given situation) used to 
> provide file & line number
> 2/ some (random) backtraces you've seen recently don't provide file & 
> line number
>
> If the later, that's normal (in some cases). For addresses (in a bt) 
> for which we don't find a function, we just print the name of the 
> module and the offset from the start of the module, but no file & line 
> number (since we don't have a function)
> If the former, that's not normal. What does the attached patch do ?
> A+
> Index: memory.c
>
> RCS file: /home/cvs/cvsroot/wine/wine/programs/winedbg/memory.c,v
> retrieving revision 1.13
> diff -u -u -r1.13 memory.c
> --- memory.c    8 Nov 2004 20:25:55 -0000    1.13
> +++ memory.c    13 Nov 2004 15:05:31 -0000
> @@ -552,7 +552,7 @@
>      /* grab module where symbol is. If we don't have a module, we 
> cannot print more */
>      im.SizeOfStruct = sizeof(im);
>      if (!SymGetModuleInfo(dbg_curr_process->handle, 
> isf.InstructionOffset, &im))
> -
>    return;
> -
>    strcmp(im.ModuleName, "<--NoModule-->");
>
> si->SizeOfStruct = sizeof(*si);
>    si->MaxNameLen   = 256;

[Eric Pouech]

jeffl a écrit :
> Eric, it is number one.
>
> Eg:
> > 1 0x40912b8f GDI_GetObjPtr+0x197(handle=0x107f, magic=0xffff) 
> > [/winf/dlls/gdi/gdiobj.c:861] in gdi32 (0x4073fcac)
> >   2 0x40912c71 DeleteObject+0x39(obj=0x107f) 
> > [/winf/dlls/gdi/gdiobj.c:919] in gdi32 (0x4073fccc)
>
> as it was last week and
> > 3 0x40915afd GDI_GetObjPtr+0x105 in gdi32 (0x4073fcac)
> >   4 0x40915c35 DeleteObject+0x39 in gdi32 (0x4073fccc)
>
> as it was after the last CVS update.  I assume that there has been a 
> config change that has turned off debugging info.

I found the issue. Basically, it's due to a recent change where for consistency with Windows, we moved some internal sizes from 
32 bit to 64 bit and not all the changes have been made.
Unfortunately, since there's a back log of patches regarding dbghelp (and winedbg), I'll wait for those to be applied, and I'll 
send the fix afterwards (likely by the end of next week).
Thanks for reporting the issue.
A+