Log in

Troubles running multiple instances of SBCL... 
29th-May-2008 01:15 pm

I started playing with writing UFFI bindings for OpenMPI. I think I have this down, but I can't truly test it at home because I only have SBCL installed on one machine, and I am having a terrible time getting even the simplest SBCL program to run twice at the same time.

Here's my run.sh shell script.


exec sbcl --noinform \
    --end-runtime-options \
    --no-sysinit \
    --no-userinit \
    --noprint \
    --disable-debugger \
    --eval '(format t "Hi from Lisp!~%")' \
    --eval '(sb-ext:quit)' \

If I do ./run.sh then everything works just as I would expect. And, I can do ./run.sh ; ./run.sh and it runs twice.

But, if I try to do ./run.sh & ./run.sh so that they both run at the same time, I get one SEGV and one success. If I put three in the background and one in the foreground, I get three SEGVs and one success.

Thinking that maybe it tried to lock standard-in or standard-out and then freaked if it failed, I added 1> _out.$$ 2> _err.$$ < /dev/null and still had the same trouble.

I can run SBCL interactively in multiple windows so I don't think I should be hitting a memory limit. I just added a sleep 30 to the script before the exec, started the script in two different screens, killed both sleeps from another screen, and got the same result.

Any clues? I didn't find anything too useful searching the SBCL mailing lists for segmentation AND fault except some problems people had last summer getting SBCL to compile on a Mac that might be related if there's parallel building going on.

  • Darwin sirrobin.selsne.org 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
  • This is SBCL 1.0.2, an implementation of ANSI Common Lisp.

Edit: This is SBCL 1.0.17, an implementation of ANSI Common Lisp. same issue. And, I can even get rid of the (format ...) call and still trigger the same problem.

29th-May-2008 07:13 pm (UTC)
I don't know what's happening, sorry, but it's almost always easier to troubleshoot problems if you use the latest release. SBCL has new releases monthly, and the current release is 1.0.17, so 1.0.2 is over a year out of date.
29th-May-2008 08:52 pm (UTC)
Ya know... I saw that release note... but then confused myself thinking that 1.0.2 was bigger than 1.0.17.... version numbers are not decimal numbers.... duhr....

I will upgrade....

Wacky though... I'm not sure where I got SBCL from before, but I just installed 1.0.2 on February 23rd of this year.

Upgraded to 1.0.17. It still has the same problem on my PPC Mac. 8^(

Edited at 2008-05-29 09:32 pm (UTC)
30th-May-2008 05:53 pm (UTC) - Please file a bug with Apple
There isn't much SBCL does (or could do!) that should interfere with another unrelated process.

I bet you a pint and a game of pool that this is a Darwin bug.

I won't bet money though, because I don't know enough about the Mach system calls we use on Darwin to say if the problem could be there, but the POSIX parts should definitely not be capable of making a mess like that -- or at least I cannot imagine how. The bits of POSIX that could be involved are pretty much all fork & thread-related, but since it's the shell that is forking and not SBCL, it doesn't sound like the probable cause.

Finally, generally speaking we really like hearing about this sort of stuff on sbcl-devel or sbcl-help. :)


-- Nikodemus
30th-May-2008 09:49 pm (UTC) - Re: Please file a bug with Apple
I subscribed to sbcl-help yesterday so that I could post this very problem. But, I haven't found time to do that yet. I was going to try to gleen something useful in gdb first. Looking at the core file isn't easy. There is no stack info and no symbols near where it dies.

Thanks though. I'll email sbcl-help soon.
This page was loaded Sep 2nd 2015, 11:44 pm GMT.