Kernel Panic on SBCL Compile

Bug #1391705 reported by Alex
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Incomplete
Undecided
Unassigned

Bug Description

I am on a Mac Pro with Yosemite. I am installing sbcl using HomeBrew. Every time I execute `brew install sbcl`, I eventually get a kernel panic during the make command. HomeBrew is trying to compile sbcl 1.2.2. It appears it is specifically the process sbcl that is causing the panic. It looks like the sbcl process is trying to create a specifically-named IPC entry, but the name is beyond the maximum allowable size of the port namespace.

Revision history for this message
Alex (worthless-trash-junk) wrote :
Revision history for this message
Alex (worthless-trash-junk) wrote :

The attached log is everything output by `brew -v install sbcl` up until the kernel panic.

Revision history for this message
Zach Beane (xach) wrote :

This doesn't happen when doing a standard build of SBCL from source on Yosemite for me. 1.2.5 also compiles without any issue.

Revision history for this message
Alex (worthless-trash-junk) wrote :

It doesn't happen for me on my MacBook Pro with Yosemite, either. I'm sure it isn't happening for most people. But, on my Mac Pro it's 100% reproducible. I'm curious if there's anything unusual in the log file that I attached, or what exactly is happening in the log file right before it's terminated. I don't know any LISP. I was hoping to install it and learn it via SBCL. Does sbcl do any inter-process communication during its build?

Revision history for this message
Stas Boukarev (stassats) wrote :

User space code shouldn't be able to trigger a kernel panic, and I don't see anything out of the ordinary at the end of that log file.

Revision history for this message
Alex (worthless-trash-junk) wrote :

Yes, at the end of the day any kernel panic is definitely the kernel's fault. I have separately filed with Apple for their kernel bug. But, it looks like sbcl is misbehaving to cause the kernel panic, so I'm interested in what's going on there. Thanks for looking at the sbcl log. In the panicked state:

(lldb) showipcsummary # first few sorted by tablesize:
task pid #acts tablesize command
0xffffff805d66ea10 15078 17 127317 sbcl
0xffffff8039918718 1 5 5120 launchd.developm
0xffffff803b1e4718 48 16 1194 opendirectoryd
0xffffff8039916000 24 2 1194 appleeventsd
0xffffff8041ef9458 248 27 1024 Mail
0xffffff804215c5b8 255 7 682 SystemUIServer

Do you have any idea why sbcl would try to have such a massive ipc table during its make?

Revision history for this message
Stas Boukarev (stassats) wrote :

It's not even during compiling sbcl, but when building contribs, according to the log, the sb-sprof contrib. Can you trigger it by just doing ./make-target-contribs.sh sb-sprof or just ./make-target-contribs.sh ?

Revision history for this message
Stas Boukarev (stassats) wrote :

Make that sb-posix.

Revision history for this message
Alex (worthless-trash-junk) wrote :

Well, building the sbcl-1.2.2 sources myself using the sbcl-1.1.8 MacOSX x86_64 binary as the bootstrap LISP interpreter with nothing more than `sh make.sh` succeeded.

It looks like something specific to HomeBrew's installation procedure is causing it. I'm using the same sbcl 1.2.2 source and the same sbcl-1.1.8 bootstrap binary that HomeBrew uses.

It looks like the exact command used by HomeBrew for build is:
./make.sh --prefix=/usr/local/Cellar/sbcl/1.2.2 --xc-host=/private/tmp/sbcl--bootstrap64-0pUAlH/sbcl-1.1.8-x86-64-darwin/src/runtime/sbcl --core /private/tmp/sbcl--bootstrap64-0pUAlH/sbcl-1.1.8-x86-64-darwin/output/sbcl.core --disable-debugger --no-userinit --no-sysinit

When I try running that myself, I"m told "--core" is an unknown make-config.sh option. It looks like I need to go over to HomeBrew and file a bug to better understand what they're doing.

Revision history for this message
Alex (worthless-trash-junk) wrote :
Revision history for this message
Stas Boukarev (stassats) wrote :

it would be ./make.sh --prefix=/usr/local/Cellar/sbcl/1.2.2 --xc-host="/private/tmp/sbcl--bootstrap64-0pUAlH/sbcl-1.1.8-x86-64-darwin/src/runtime/sbcl --core /private/tmp/sbcl--bootstrap64-0pUAlH/sbcl-1.1.8-x86-64-darwin/output/sbcl.core --disable-debugger --no-userinit --no-sysinit"

Revision history for this message
Alex (worthless-trash-junk) wrote :

Ah, thanks. I got my quotes wrong. Again, this command runs and compiles fine for me when I execute it manually. The final difference seems to be that HomeBrew applies 4 patches to the 1.2.2 source before building:
==> Downloading https://trac.macports.org/export/88830/trunk/dports/lang/sbcl/files/patch-base-target-features.diff
==> Downloading https://trac.macports.org/export/88830/trunk/dports/lang/sbcl/files/patch-make-doc.diff
==> Downloading https://trac.macports.org/export/88830/trunk/dports/lang/sbcl/files/patch-posix-tests.diff
==> Downloading https://trac.macports.org/export/88830/trunk/dports/lang/sbcl/files/patch-use-mach-exception-handler.diff

I'll try applying these to my manual build and see if it reproduces.

Revision history for this message
Alex (worthless-trash-junk) wrote :

It reproduces without HomeBrew when I apply the patch-base-target-features.diff(1) and build with the above make command.

This patch enables the sb-threads feature. Any idea how this might affect the build and cause the IPC problem?

(1) https://trac.macports.org/export/88830/trunk/dports/lang/sbcl/files/patch-base-target-features.diff

Revision history for this message
Stas Boukarev (stassats) wrote :

There's no reason to add :darwin there, for one thing.

Revision history for this message
Stas Boukarev (stassats) wrote :

Threads are not enabled default, so, that would be why it fails only after that patch.
(And there's no reason to modify that file at all, there is --with-sb-thread and customize-target-features.lisp for that purpose).

Revision history for this message
Alex (worthless-trash-junk) wrote :

Curiously, the panic does not reproduce when I use this switch instead of the patch:

With no patches,
./make.sh --prefix=/usr/local/Cellar/sbcl/1.2.2 --xc-host="/Users/admin/Downloads/sbcl-1.1.8-x86-64-darwin/src/runtime/sbcl --core /Users/admin/Downloads/sbcl-1.1.8-x86-64-darwin/output/sbcl.core --with-sb-thread --disable-debugger --no-userinit --no-sysinit"

Revision history for this message
Alex (worthless-trash-junk) wrote :

It appears to have actually compiled sb-thread support with the switch because "sb-thread" is mentioned several times throughout the compile log, and there are a number of sb-thread tests that all pass when I run the regression tests after build.

Revision history for this message
Stas Boukarev (stassats) wrote :

It's not that curios because --with-sb-thead is at the wrong place.

Revision history for this message
Alex (worthless-trash-junk) wrote :

Where should it be?

Revision history for this message
Alex (worthless-trash-junk) wrote :

From reading the INSTALL, it looks like this is the proper command:

./make.sh --with-sb-thread --prefix=/usr/local/Cellar/sbcl/1.2.2 --xc-host="/Users/admin/Downloads/sbcl-1.1.8-x86-64-darwin/src/runtime/sbcl --core /Users/admin/Downloads/sbcl-1.1.8-x86-64-darwin/output/sbcl.core --disable-debugger --no-userinit --no-sysinit"

Indeed, with this command the kernel panic occurs.

Is it possible to turn off the tests that are run during compile? I've seen it kernel panic right as it begins to run SB-CONCURRENCY tests.

Revision history for this message
Cyrus Harmon (ch-launchpad) wrote :

Have you tried newer and/or older SBCLs?

Clearly there's a kernel problem -- user code shouldn't ever make the kernel panic. Just to be sure, you're not doing this as root are you? And have you tried this same thing on a different computer?

kernel problem aside, it would be nice to better understand why this is crashing. I'm curious to know what a vanilla make.sh (with threads enabled) on the latest HEAD does.

Revision history for this message
Alex (worthless-trash-junk) wrote :

No, I haven't yet tried new or older versions of SBCL. I'll give latest HEAD a try.

Yes, I've done this same thing on two MacBook Pros and it works just fine. It's only on my new Mac Pro that it kernel panics.

No, I'm not doing this as root.

Indeed, any kernel panic is a kernel bug. I've filed that with Apple.

Revision history for this message
Alex (worthless-trash-junk) wrote :

I just got master from https://github.com/sbcl/sbcl and built with this command:

./make.sh --with-sb-thread --xc-host="/Users/admin/Downloads/sbcl-1.1.8-x86-64-darwin/src/runtime/sbcl --core /Users/admin/Downloads/sbcl-1.1.8-x86-64-darwin/output/sbcl.core"

I must specify the location of the sbcl binary and core because I don't already have a built and installed version of sbcl on this machine.

Same results. Kernel panic.

I wonder if using a newer version of the binary and core might help. I'll try using a more recent sbcl build from one of my mother Macs.

Revision history for this message
Alex (worthless-trash-junk) wrote :

I built HEAD on a different Mac that doesn't produce the kernel panic using `./mash.sh --with-sb-threads` and used the resulting sbcl binary and sbcl.core to try building HEAD on my Mac Pro.

I still got the kernel panic trying to build HEAD on my Mac Pro with the above binaries and the command:
./make.sh --with-sb-thread --xc-host="/Users/admin/Downloads/sbcl --core /Users/admin/Downloads/sbcl.core"

No progress. :/

Revision history for this message
Alex (worthless-trash-junk) wrote :

mash.sh -> make.sh

Revision history for this message
Alex (worthless-trash-junk) wrote :

I just transferred the entire sbcl repository directory after building it from my other Mac to my Mac Pro and tried running tests/run-tests.sh.

The kernel panic occurred. Indeed, it seems the panic is caused by one of the tests. Again, it panicked around the threading tests. I will see if I can narrow it down to a specific test. It must be one of the tests associated with sb-threads.

Revision history for this message
Stas Boukarev (stassats) wrote :

What kind of information can you get after the panic? A backtrace or something?

Revision history for this message
Cyrus Harmon (ch-launchpad) wrote : Re: [Bug 1391705] Re: Kernel Panic on SBCL Compile

Well, it's nice to know that it is something that is 1) reproducible and
2) occurs on the latest and greatest sources. It's never any fun to
track down bugs that only exist in obsolete versions of things. Now, if
only I had a new Mac Pro on which to try this... Last I checked,
threaded builds worked fine on my vintage 2007 MacPro -- but the new
ones are quite different. I wouldn't be surprised if the critical
variable here is number of cores and somehow the 64/32 bit games we play
with mach ids runs afoul of some numbering conventions once we got over
a certain number of cores.

On 11/19/2014 05:22 PM, Alex wrote:
> I just transferred the entire sbcl repository directory after building
> it from my other Mac to my Mac Pro and tried running tests/run-tests.sh.
>
> The kernel panic occurred. Indeed, it seems the panic is caused by one
> of the tests. Again, it panicked around the threading tests. I will
> see if I can narrow it down to a specific test. It must be one of the
> tests associated with sb-threads.
>

Revision history for this message
Cyrus Harmon (ch-launchpad) wrote :

Also, I assume this is a 64-bit build right, have you tried a 32-bit build?

On 11/19/2014 05:22 PM, Alex wrote:
> I just transferred the entire sbcl repository directory after building
> it from my other Mac to my Mac Pro and tried running tests/run-tests.sh.
>
> The kernel panic occurred. Indeed, it seems the panic is caused by one
> of the tests. Again, it panicked around the threading tests. I will
> see if I can narrow it down to a specific test. It must be one of the
> tests associated with sb-threads.
>

Revision history for this message
Alex (worthless-trash-junk) wrote :

I know the HomeBrew installer does an x86-64 build.

I haven't been specifying any architecture option when manually building HEAD, so I can't be sure what it's building.

I didn't see in the INSTALL file any mention of how to specify an x86 build. How do I do that?

Attached is sbcl.stack, which is a stack from user space in the panicked state. However, it isn't very useful since none of the calls are symbolicated.

Revision history for this message
Alex (worthless-trash-junk) wrote :

Can I get direction on how to specify a 32 bit build? It isn't mentioned in the INSTALL file.

Revision history for this message
Stas Boukarev (stassats) wrote :

./make.sh --arch=x86

Revision history for this message
Alex (worthless-trash-junk) wrote :

Many thanks! Same kernel panic with:

./make.sh --with-sb-thread --arch=x86 --xc-host="/Users/admin/Downloads/sbcl --core /Users/admin/Downloads/sbcl.core"

I'll try to narrow down exactly which test is causing the panic.

Stas Boukarev (stassats)
Changed in sbcl:
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.