Search
Thursday, 21st of September 2017, 15:19:11 UTC
15:22:54
|3b|
how do i build with sb-thruption on linux?
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'"
15:24:30
|3b|
and undefined reference to wake_thread_posix in thread.c
15:25:30
|3b|
ACTION tries with sb-safepoint too
15:26:01
|3b|
yeah, looks like it got past .c stuff with that
15:31:52
|3b|
and can't reproduce the problem on sbcl/linux with safetpoint+thruption
15:32:02
|3b|
(running through ssh, though not sure that matters)
16:01:08
|3b|
stassats: i think the problem is in slime, in https://github.com/slime/slime/blob/master/swank.lisp#L445
16:01:45
|3b|
or else the sbcl implementation of wake-thread
16:02:05
stassats
what problem is in there?
16:02:46
|3b|
https://github.com/slime/slime/blob/master/swank/sbcl.lisp#L1753
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:04:11
|3b|
i guess 3rd option is that that mutex should allow recursive locks
16:06:59
stassats
does it hold it, though?
16:08:27
|3b|
it just exited the without-interrupts in call-with-mutex
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:10:27
|3b|
yeah, i think this is the other one, so might be slightly different
16:13:13
stassats
i think invoke-or-queue-interrupt doesn't return nil enough
16:14:34
stassats
can you put NIL in all branches but the last one?
16:16:06
|3b|
i think it was going through the T path
16:16:19
stassats
probably, since it does work normally
16:17:32
|3b|
and looks like C-c C-b in .lisp buffers is broken too, so not specific to repl
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:25:30
stassats
sb-thread:condition-wait maybe just broken on windows thne
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:27:13
|3b|
i guess it is possible both are broken though
16:27:58
|3b|
well, seems like the interrupts are happening at places they are allowed to
16:28:34
|3b|
and if they should be allowed there, the problem is grabbing the mutex from the interruption
16:28:49
|3b|
no idea if they should be allowed there or not :)
16:37:59
stassats
well, it works on linux and macos, so somethings must be not right on windows
16:38:48
|3b|
yeah, seems OK with that change reverted
16:54:50
stassats
i guess i see, it's precisely because it interrupts in the safe places
16:55:08
stassats
but the safe place on safepoint makes it exit condition-wait and grab the mutex again
17:00:46
stassats
|3b|: a fix i pushed works here
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
19:54:53
copec
well, google -> http://www.sbcl.org/sbcl-internals/
19:55:05
copec
So I guess the manual needs updated.
Friday, 22nd of September 2017, 3:19:11 UTC