freenode/#sbcl - IRC Chatlog
Search
9:11:31
knobo
What is this: Unexpected error 9 on netlink descriptor 6fatal error encountered in SBCL pid 17146(tid 0x7fffe70bf700):
9:16:37
|3b|
supposedly that error is usually due to closing wrong FDs in another thread or something like that
9:33:42
|3b|
calling twice sounds bad (particularly if another thread might have opened it again in between), or closing an fd that is in use by another thread
12:03:08
|3b|
hmm, C-c C-c when cursor is on a lambda form in slime repl kills sbcl with nested errors
12:06:25
|3b|
ACTION wonders if there is something wrong with my slime, seems to have been having trouble with source locations lately too
12:28:30
|3b|
test case is start slime, type (lambda()) move left 2 chars, hit C-c C-c, exit debugger if it gives normal interrupt, hit C-c C-c again, -> spam about nested errors -> crash
12:48:06
|3b|
ACTION also wonders if it is intended that (cffi:foreign-funcall-pointer p nil :void) gives optimization notes at debug 3, speed 1
12:50:18
|3b|
hmm, just noticed last attempt left a meaningful error message in debugger: Recursive lock attempt #<SB-THREAD:MUTEX owner: #<SB-THREAD:THREAD "repl-thread" RUNNING {100AA00033}> {100AA08783}>.
12:55:44
|3b|
ACTION is more wondering about getting the note at all at speed 1 than about its contents
12:56:36
stassats
cause apparently "oh it's so bad better fix it" yet you can't fix it because it's sb-alien
12:58:14
|3b|
ok, if it is expected i won't worry about it, and will just try to remember not to use C-u C-c C-k on that file :)
13:11:29
|3b|
and broke on (list 1 2 3) that time, so probably not specific to form, and just luck that it worked on (+ 1 2 3) before
14:55:51
_death
https://github.com/sbcl/sbcl/blob/master/src/code/defpackage.lisp#L72 <- missing optname as first argument.. (defpackage :foo (:documentation "bar" "quux"))
15:07:04
|3b|
ok, looks like receive-if is in condition-wait, and when it grabs the mutex and leaves the without-interrupts, there is an interrupt-thread waiting from the C-c C-c so before it returns from condition-wait the interrupt calls wake-thread, which tries to grab the mutex, which errors on recursive lock, then debugger loop does receive-if which tries to grab the mutex, etc
15:08:40
|3b|
and there is another place it breaks sometimes, haven't looked at it but guessing it is similar problem
15:14:45
|3b|
and somewhere in there it tries to open the debugger for the C-c C-c, but same problem there anyway
15:17:30
|3b|
ACTION leans towards slime problem at this point, but still not quite sure what should be happening well enough to tell if it is or not
15:23:58
|3b|
ACTION tried make.sh --with-sb-thruption, but that says "sbcl/src/runtime/interrupt.c:1054: undefined reference to `check_pending_thruptions'"
16:01:08
|3b|
stassats: i think the problem is in slime, in https://github.com/slime/slime/blob/master/swank.lisp#L445
16:03:40
|3b|
it interrupts the thread while the mutex is held, then wake-thread tries to get the mutex too and it breaks
16:08:53
|3b|
ACTION isn't sure if the backtrace i'm looking at is the case i was investigating earlier or the other one
16:21:52
stassats
|3b|: does it work without https://github.com/slime/slime/commit/5f23adaa88c034449d935b7a0bc26ed936d5ed0e
16:25:02
|3b|
without the wake-thread it works (aside from being slow to notice the interrupt sometimes)
16:25:26
|3b|
testing without the whole change will take a bit, need to check it out from git...just a sec
16:26:37
|3b|
i don't think it is only condition-wait, breaks in with-mutex some of the time, and in condition-wait some of the time
16:28:34
|3b|
and if they should be allowed there, the problem is grabbing the mutex from the interruption
16:55:08
stassats
but the safe place on safepoint makes it exit condition-wait and grab the mutex again
19:52:45
copec
I wonder if someone could fix this link: http://sbcl-internals.cliki.net/ under http://www.sbcl.org/manual/#Internals-Documentation