<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-16 10:45 GMT+04:00 John Marino <span dir="ltr"><<a href="mailto:dragonflybsd@marino.st" target="_blank">dragonflybsd@marino.st</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 4/16/2014 04:59, Vasily Postnicov wrote:<br>
> Thanks! I created a bug report, as it is clear now, that is  not SBCL fault.<br>
> <a href="https://bugs.dragonflybsd.org/issues/2663" target="_blank">https://bugs.dragonflybsd.org/issues/2663</a><br>
<br>
</div>Hmmm, how did you conclude that "it's not SBCL's fault"?<br>
<div class="">"So the issue here is that libpthread is not built into the main<br>
 program and it needs to be, simple as that.  If the main program is<br>
 compiled/linked with -pthread, the problem should go away."<br>
<br>
</div>Thus SBCL is not being built correctly.  It's an SBCL problem.<br>
It needs an LDFLAG of -pthread when it's built.<br>
<div class=""><br>
<br>
> I also found that any library, which mmap's some space at fixed range in<br>
> its constructor will fail the test. I attached such a library which<br>
> mimics the behaviour of libthread_xu.so<br>
<br>
</div>Again, "A lot of these shared libraries are not designed to be<br>
unloaded".  So isn't failing the test expected and not an issue?<br>
<br>
John<br>
<div class=""><br>
<br>
><br>
><br>
> 2014-04-16 5:31 GMT+04:00 Matthew Dillon <<a href="mailto:dillon@apollo.backplane.com">dillon@apollo.backplane.com</a><br>
</div>> <mailto:<a href="mailto:dillon@apollo.backplane.com">dillon@apollo.backplane.com</a>>>:<br>
<div class="HOEnZb"><div class="h5">><br>
>         Ah ha!  I found it.  Testing with dynamically loading a library<br>
>     which<br>
>         depends on libpthread triggers the problem when libpthread is not<br>
>         built into the main program.<br>
><br>
>         For example, if I test with libusb.so.2 with a program compiled<br>
>     without<br>
>         -pthread, it triggers the problem.  If I test with libusb.so.2 with<br>
>         a program compiled with -pthread, it does not trigger the problem.<br>
><br>
>         So the issue here is that libpthread is not built into the main<br>
>         program and it needs to be, simple as that.  If the main program is<br>
>         compiled/linked with -pthread, the problem should go away.<br>
><br>
>         --<br>
><br>
>         In terms of making this work as-is with some sort of fix to<br>
>     rtld-elf...<br>
>         that's problematic.  A lot of these shared libraries are not<br>
>     designed<br>
>         to be unloaded.  It would take some time to vet them all.<br>
><br>
>         For now I think the best solution is to adjust the port to<br>
>     compile/link<br>
>         SBCL with -pthread.<br>
><br>
>                                                     -Matt<br>
><br>
><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">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?<br>
<br></div><div class="gmail_extra">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.<br><br>
</div><div class="gmail_extra">So I am not telling that I found a bug, I am just asking is this behaviour OK? I think it is not.<br></div></div>