On Tue, 27 Nov 2001, Martin v. Loewis wrote: > Unlikely. The original gdb "backtrace" indicated that somebody was > jumping to address 0. I think potential causes are: > > 1. dynamic initialization of a shared library has not been carried > out. It would be interesting to verify that all shared libraries > involved do have proper .init/.fini code, i.e. have been linked > with the proper crt files.
In alpha's case in the past, the .fini code was attempting to do the same thing (jump to the address in the GP despite the address being 0). IIRC, it turned out that the code was loading the program's overall closing code first rather than the next destructor. Hence, after it ran the closing code for the program, it had nowhere to go even though it thought it did. I was wondering if this case was similar.... > 2. dynamic initialization had initialized a different location than > used when throwing the exception. That problem is known to occur > when mismatching variants of the EH code in libgcc.a have been > integrated into different shared libraries (or if both a libcc_s.so > and copies of libgcc.a are used inconsistently): That would result > in multiple copies of static variables of the EH variables. > > This isn't a problem as long as all libgcc functions resolve to the > same shared object, but is a problem if they resolve to different > libgcc copies; this happens when an out-of-libc.so copy has > additional functions that are not in libgcc. Ugh, yep. Recompiling the dependencies also with the current toolchain should fix this, correct? I'm not saying to do it, but it would be an interesting experiment if all else fails (read: weapon of last resort). C
