Can anyone help to shed the light on mysterious bug in SBCL (found it!)

[Vasily Postnicov]

2014-04-16 10:45 GMT+04:00 John Marino <dragonflybsd at marino.st>:

> On 4/16/2014 04:59, Vasily Postnicov wrote:
> > Thanks! I created a bug report, as it is clear now, that is  not SBCL
> fault.
> > https://bugs.dragonflybsd.org/issues/2663
>
> Hmmm, how did you conclude that "it's not SBCL's fault"?
> "So the issue here is that libpthread is not built into the main
>  program and it needs to be, simple as that.  If the main program is
>  compiled/linked with -pthread, the problem should go away."
>
> Thus SBCL is not being built correctly.  It's an SBCL problem.
> It needs an LDFLAG of -pthread when it's built.
>
>
> > I also found that any library, which mmap's some space at fixed range in
> > its constructor will fail the test. I attached such a library which
> > mimics the behaviour of libthread_xu.so
>
> Again, "A lot of these shared libraries are not designed to be
> unloaded".  So isn't failing the test expected and not an issue?
>
> John
>
>
> >
> >
> > 2014-04-16 5:31 GMT+04:00 Matthew Dillon <dillon at apollo.backplane.com
> > <mailto:dillon at apollo.backplane.com>>:
> >
> >         Ah ha!  I found it.  Testing with dynamically loading a library
> >     which
> >         depends on libpthread triggers the problem when libpthread is not
> >         built into the main program.
> >
> >         For example, if I test with libusb.so.2 with a program compiled
> >     without
> >         -pthread, it triggers the problem.  If I test with libusb.so.2
> with
> >         a program compiled with -pthread, it does not trigger the
> problem.
> >
> >         So the issue here is that libpthread is not built into the main
> >         program and it needs to be, simple as that.  If the main program
> is
> >         compiled/linked with -pthread, the problem should go away.
> >
> >         --
> >
> >         In terms of making this work as-is with some sort of fix to
> >     rtld-elf...
> >         that's problematic.  A lot of these shared libraries are not
> >     designed
> >         to be unloaded.  It would take some time to vet them all.
> >
> >         For now I think the best solution is to adjust the port to
> >     compile/link
> >         SBCL with -pthread.
> >
> >                                                     -Matt
> >
> >
>

I don't know. Anyway, why user should care? Imagine that I'm trying to
unload not pthread itself (which, of course, I must not do), but a random
library foo.so, which depends on pthreads indirectly. So why it must break
otherwise working application? Especially if it is not multithreaded?

And adding -lpthread to SBCL is not necessary if it is not multithreaded.
It's just a hack which prevents unloading of libthread_xu by keeping its
reference counter above zero.

So I am not telling that I found a bug, I am just asking is this behaviour
OK? I think it is not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140416/8270faa7/attachment-0002.html>