Re: sigsegv?

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Nov 12, 2003, at 7:38 AM, Andrew Haley wrote:

> > Does this ring a bell for anybody?
> >
> > #0  0x42073771 in free () from /lib/tls/libc.so.6
> > #1  0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6
> > #2  0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6
> > #3  0x4038ed55 in __do_global_dtors_aux ()
> >    from /home/tromey/gnu/Trunk/install/lib/libgcj.so.4
> > #4  0x406563a6 in _fini () from 
> > /home/tromey/gnu/Trunk/install/lib/libgcj.so.4
> > #5  0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2
> > #6  0x42029d40 in exit () from /lib/tls/libc.so.6
> > #7  0x08048bee in main (argc=1, argv=0xbfffedf4)
> >     at ../../../gcc/libjava/gij.cc:163
> >
> >
> > This is the result of just running "gij".
> > This is with a completely fresh build as of last night.  Nothing on
> > my machine has changed, it must be some new gcc bug.
>
> I'm getting this too.
>
> I didn't get it when I did my cast checkin a few days ago.
>
> LD_ASSUME_KERNEL=2.4.17 does indeed fix the problem.
>
> Jeff, how did you discover this?

Uhh, who me? ;-)

Setting LD_ASSUME_KERNEL is a reflex action whenever I get weird 
crashes. It tells glibc to use safe fallbacks for things that may be 
incompatible with recent kernels/binutils/etc.

I guess the next step to track this down would be to either use a debug 
glibc build, or try to figure out which GCC change caused it to happen. 
(BTW the problem also goes away with a more recent glibc)

Regards

Bryce