From: Godmar Back (gback@cs.utah.edu)
Date: Sat Feb 06 1999 - 23:18:51 EST
>
> This is a MIME multipart message. If you are reading
> this, you shouldn't.
>
> --=-=-=
>
> On Feb 7, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>
> >> I've got good and bad news: as soon as I moved initNativeThreads() to
> >> after initNative(), I didn't get any segmentation fault on
> >> Solaris/sparc and any failure to find libnative on GNU/Linux/x86. So
> >> there really *is* something going on between the signal handler and
> >> dlopen.
>
> > Note that I not only got the failure to find libnative problem,
> > I got actual segfault because the library was linked half-way.
>
> Yep. In fact, I've just got this problem with libio on Solaris :-(
>
> So delaying the initialization of the threading system doesn't really
> fix the problem, just hides it better.
>
Could the problem be the mmap()?
>
> But the problem is deep within dlopen, probably within the code that
> relocates the library jump table (I couldn't get function names :-(
I showed you how it screwed up the function table in LInux.
>
> It's attached. But I'm no longer sure it's a good idea to install it.
> It will just hide a bug that will remain present and cause Kaffe to
> crash unexpectedly :-(
It wouldn't work with pthreads OSKit cause the threading system must be
initialized before we initialize locks in stringInit() etc.
>
> However, I have completed a dozen runs of the testsuite on
> GNU/Linux/x86 without any problems now. But I didn't have that much
> luck on Solaris :-(
Well, in this case, simply try to explicitly block and unblock all
signals before and after the call to dlopen & friends.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:59 EDT