This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Random failures when calling free()/malloc()
> Ok, I plugged a few holes, and if you look at:
>
> ----------------------------
> #0 0x405ee1e1 in malloc_consolidate (av=3D0x406a37e0) at malloc.c:4355
> #1 0x405eda58 in _int_malloc (av=3D0x406a37e0, bytes=3D25) at malloc.c:379=
> 4
> #2 0x405ece0b in __libc_malloc (bytes=3D504) at malloc.c:3293
> #3 0x4053424e in g_malloc (n_bytes=3D504) at gmem.c:136
> ----------------------------
>
> Where __libc_malloc() here is public_mALLOc(), it looks like
> __libc_malloc() (public_mALLOc()) is called as:
>
> __libc_malloc(504)
>
> but then it ends up with the arg set to 25 which it uses to call
> __int_malloc()?
I noticed that in your initial stack traces, too, however it is
quite "normal" that gdb stack dumps are wrong -- in particular for
optimized code.
> Can this be some sort of issue with how args are passed to
> functions (gcc/kernel side) ?
Unlikely. I think you're either seeing stack corruption (really
bad to track down :-( ) or you're seeing a wrong stack dump from
gdb which doesn't understand gcc's optimizations.
> I am not the greatest of debuggers, so a hand would be appreciated.
You should compile a glibc or at least a malloc module without
optimization and see wether the problem can be reproduced.
valgrind of course would be much better still.
Regards,
Wolfram.