[Fwd: program crash in malloc for gcc2.95.3 on solaris 2.8]

[Phil Edwards]

On Fri, May 17, 2002 at 03:44:44PM -0700, Howard Tsai wrote:
> (gdb) where
> #0  0xff0c2194 in realfree () from /usr/lib/libc.so.1
> #1  0xff0c2aa0 in cleanfree () from /usr/lib/libc.so.1
> #2  0xff0c1bd4 in _malloc_unlocked () from /usr/lib/libc.so.1
> #3  0xff0c1ac8 in malloc () from /usr/lib/libc.so.1
> #4  0xff1dac98 in __builtin_new (sz=12) at ./cp/new1.cc:84
> #5  0x1a01ec in ctf_initialize (ctf=0x44c258, tname=0x2c74c8 "LI_CDR",
> location=0x2c74d0 "TF", threshold=100, hwm=10000,
>     lwm=9000) at ctf_sender_c.C:74
> #6  0x21fd04 in utf_init_li_sender () at ctf_cdrs.C:107
> #7  0x99818 in llcmm_init_priv () at mm_init.c:855
> #8  0x89d38 in mminit () at mm_base.c:1026
> #9  0x18de08 in utf_stremul_main (argc=3149148, argv=0x0) at emul.c:114
> #10 0x14fb4 in thr_stream_main ()

This is almost universally a sign of your code corrupting the heap where
Sun's malloc libraries store housekeeping information.  I recommend
reading the man pages on Solaris' (very useful) watchpoint facility, and
then using the "watchmalloc" library to freeze the program at the point
when the housekeeping information is damaged.  The use pstack to find the
culprit function.

In any case, it is unlikely that the bug is in the compiler itself.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams