Can anyone help to shed the light on mysterious bug in SBCL (found it!)
dragonflybsd at marino.st
Tue Apr 15 23:45:21 PDT 2014
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.
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?
> 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
> 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
> -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
> that's problematic. A lot of these shared libraries are not
> 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
> SBCL with -pthread.
More information about the Users