Steel Bank Common Lisp

slime-autodoc causes crash under mac os x mountain lion dp4

Reported by Mark on 2012-06-13
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
SBCL
Undecided
Unassigned

Bug Description

When my cursor goes on s-exp all seems to be ok, but when I move it off from s-exp I get this error:
  Error opening /dev/tty: Device not configured

I've tried to disable slime-autodoc and all seems to be fine. So I think the bug is in this module.

Stas Boukarev (stassats) wrote :

Can you expand on what Emacs are you using and what Common Lisp implementation?

Changed in slime:
status: New → Incomplete
Stas Boukarev (stassats) wrote :

And to help debug it more, do M-x toggle-debug-on-error and M-x slime-toggle-debug-on-swank-error and post backtraces here.

Mark (hitecnologys) wrote :

I'm using emacs 23.4.1, sbcl 1.0.57.49-d720bc3.

Enabled both options but got the same result, nothing changes:

fatal error encountered in SBCL pid 21551(tid 8465408):
mach_port_allocate_name failed with return_code 5

Error opening /dev/tty: Device not configured
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb> backtrace
Backtrace:
   0: Foreign function ldb_monitor, fp = 0x420bd90, ra = 0x109a86
   1: Foreign function call_lossage_handler, fp = 0x420bda0, ra = 0x10632a
   2: Foreign function lose, fp = 0x420be90, ra = 0x106571
   3: Foreign function mach_thread_init, fp = 0x420beb0, ra = 0x1107af
   4: Foreign function arch_os_thread_init, fp = 0x420bee0, ra = 0x110555
   5: Foreign function new_thread_trampoline, fp = 0x420bf10, ra = 0x10dea1
   6: Foreign function _pthread_start, fp = 0x420bf50, ra = 0x7fff842cc4a2
   7: Foreign function thread_start, fp = 0x420bf78, ra = 0x7fff842b8ee1

What I did wrong?

Stas Boukarev (stassats) wrote :

Well, that's a totally different thing. SBCL gets completely hosed, the error about /dev/tty is irrelevant. I have no access to OS X, so I have no idea why it's failing.
And since I doubt that slime is to blame here, I'll also link this bug to SBCL.

Nikodemus Siivola (nikodemus) wrote :

Output from uname -a?

Directions to reproduce?

Mark (hitecnologys) wrote :

Darwin MacBook-Air-Mark.local 12.0.0 Darwin Kernel Version 12.0.0: Tue May 8 17:30:17 PDT 2012; root:xnu-2050.5.8~1/RELEASE_X86_64 x86_64

First, as I have Mountain Lion (gcc was replaced by clang and clang can't compile most sources), I've installed this: https://github.com/kennethreitz/osx-gcc-installer.

Then I've installed homebrew and installed emacs. After that I've downloaded slime and par edit. (.emacs file in attachment as 'emacs').

Then I've downloaded latest sources of sbcl from official repository and buit it with `sh make.sh --fancy`. From the console it works OK. But when I'm trying to run it with slime and slime-autodoc enabled it ceases when I'm trying to get doc for symbol **the second time**.

Sorry for my English.

Mark (hitecnologys) wrote :

Hm, tried to recompile sbcl with different features enables. Seems that problem is in the treading, --without-sb-thread solved all problems. Anyway something needs fixing 'cause it worked on OSX 10.7. I know that the support is experimental but it's strange that it worked on previous generation of OSX.

I think there may be an issue with SBCL 1.0.57 x64 on OS X Mountain Lion (10.8). I am running the official version released this week, and I cannot build a multi-threaded 1.0.57 of SBCL. Instead of the usual nice message about running "sh install.sh" to install the built product, the build ends with just this:

; SYS:CONTRIB;SB-SPROF;SB-SPROF.FASL.NEWEST written
; compilation finished in 0:00:00.791
* true

WARNING! Some of the contrib modules did not build successfully or pass
their self-tests. Failed contribs:"
  sb-concurrency

I normally have :sb-thread in my enabled features; if I remove it (to build a single-threaded SBCL), the build completes as expected and appears usable (have not done heavy testing yet).

I have a fairly plain vanilla environment: Emacs 24.1 from emacsformacosx.com, Slime et al. are from latest Quicklisp, and SBCL is built from the 1.0.57 tag.

Also, i have the latest gcc (and thus clang, I'm sure) as installed by the shipping XCode.

I'd be happy to test build any patches, or otherwise help explore what's going on. Just need some guidance. :)

Mark.Evenson (evenson-not-org) wrote :

The mach_port_allocate_name call is failing:
{{{
; /Users/evenson/src/sbcl-1.0.57/contrib/sb-concurrency/tests/ASDF-TMP-test-gate.fasl written
; compilation finished in 0:00:00.011
Doing 24 pending tests of 24 tests total.
 SB-CONCURRENCY-TEST::QUEUE.1 SB-CONCURRENCY-TEST::QUEUE.2
 SB-CONCURRENCY-TEST::QUEUE.3 SB-CONCURRENCY-TEST::QUEUE.4
 SB-CONCURRENCY-TEST::QUEUE.5 SB-CONCURRENCY-TEST::QUEUE.T.1
fatal error encountered in SBCL pid 7239(tid 8449024):
mach_port_allocate_name failed with return_code 5

make: *** [test] Error 1
make -C ../asdf
}}}

Researching the syscall (apparently not listed/indexed in the OS X 10.8 man pages: tsk, tsk AAPL).
{{{
dada:~/src/sbcl-1.0.57$ uname -a
Darwin dada.local 12.0.0 Darwin Kernel Version 12.0.0: Sun Jun 24 23:00:16 PDT 2012; root:xnu-2050.7.9~1/RELEASE_X86_64 x86_64
}}}

While I'm not an SBCL contributor, I was encountering these issues and saw them being discussed on IRC. This fix (and the one before it) may address the issue--or at the very least, a closely related one:

https://github.com/sbcl/sbcl/commit/578362575fc2112b828597cc1025e3ead43d43ba

Mark (hitecnologys) wrote :

The bug seems to be solved. Just compiled new version of sbcl with --fancy and it works perfect on 10.8 GM. I'm unable to test it on release version but I think it will work as GM and release are almost the same. You can close this bug now.

Stas Boukarev (stassats) on 2012-08-12
no longer affects: slime
Paul Khuong (pvk) on 2012-08-13
Changed in sbcl:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments