Re: [Valgrind-users] Valgrind won't print the complete stacktrace if the bug is an unitialized argument to a function *written in assembly*

[Guilhem B. <gu...@my...>]

On Mon, 2003-09-29 at 19:11, Nicholas Nethercote wrote:
> On Sun, 28 Sep 2003, Guilhem Bichot wrote:
> 
> > I thought this was of interest, if you sometimes can't get Valgrind to
> > print the complete stacktrace.
> 
> [snip]
> 
> > Using valgrind --gdb-attach=yes does not help, as the frames you can
> > access in gdb are not "interesting" (they're only some obscure Valgrind
> > code vg_*.c and you can't go up in the stack).
> 
> [snip]
> 
> > The reason why Valgrind does not give the stacktrace for str->set() is
> > that the String::set(longlong) function is:
> >   str_length=(uint32) (longlong10_to_str(num,Ptr,-10)-Ptr);
> > and in MySQL longlong10_to_str is not C code but assembly code
> > (i.e we call a function written in assembly, from the C code).
> 
> Valgrind finds its traces by walking the stack.  AIUI, this relies on your
> program using %ebp as a frame pointer.  I think this is normal for
> compiled C code (unless you use -fomit-frame-pointer), but it probably
> isn't the case in your asm code.  So Valgrind can't work out where the
> stack frame boundaries are.  I would guess that GDB doesn't find anything
> "interesting" for the same reason.
> 
> So I don't think there's an easy solution, sorry.
> 
> N

True, in this asm code we use %ebp for other things than as a frame pointer.
And (I just tested) when I disable the optimised asm functions and use C
equivalent functions instead, I get the beautiful stacktrace.
Thank you very much for this explaination!

Guilhem