Re: [CVS] commit

Date view Thread view Subject view Author view

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


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:59 EDT