Random failures when calling free()/malloc()

[wmglo@dent.med.uni-muenchen.de]

> 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.