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

[Vasily Postnicov]

> Why would you build SBCL to only do single threaded applications?
Because multithreading is not easy in SBCL. Currently, I have no idea how
to implement it. For all other platforms -lpthread is used only for
multithreaded SBCL (see sbcl-source/src/runtime/Config.x86-64-freebsd for
example).
It is strange to supply -lpthread to single threaded app just to avoid some
bugs, is it not? But I've already done it as a temporal (I hope!) solution.

> or did I misunderstand and the executable built by the SBCL compiler has
to be linked with pthread and not the compiler itself?
No. pthread is being loaded indirectly via rtld  when user (programmer)
wants to load any library depending on it. In case of IOLib, SBCL
loads(with dlopen) libfixposix which is linked against pthread.

Just to clear the situation: no, I do not want to save the linker from
loading pthreads, and, yes, it would be nice to prevent libthread_xu from
allocating the stack guard page for main thread twice.

>  please provide all the patches you are using (including this -pthread
addition when you figure it out)
Sure. Build it with "sh make.sh --xc-host=clisp". Do not forget to run all
tests: "cd tests && sh run-tests.sh". They must pass, but it will be better
to doublecheck. I attach the patch as a single file, will that do?


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

> On 4/16/2014 15:17, Vasily Postnicov wrote:
>
> > 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?
>
> I don't get why this matters.  Your problem has been solved. Build the
> executable with -pthread and the issue goes away.  Why would you build
> SBCL to only do single threaded applications?  That doesn't make sense
> to me.  You build it with -pthread, then it can do both single and
> multithread.  Are you trying to save the dynamic linker from loading
> pthread library?
>
> or did I misunderstand and the executable built by the SBCL compiler has
> to be linked with pthread and not the compiler itself?
>
>
> > 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.
>
> yes, why not?
> It's the first time any kind of issue has come it, and it's probably
> related to how SBCL was designed, so it seems pretty application
> specific, not a general problem.  At least to me, given only what I've
> skimmed on this list.
>
> If you want SBCL on DragonFly, please provide all the patches you are
> using (including this -pthread addition when you figure it out) or
> submit them to upstream and we'll eventually get them from ports.
>
> Thanks,
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140416/fc56bba4/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sbcl.patch
Type: text/x-patch
Size: 33757 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20140416/fc56bba4/attachment-0016.bin>