freenode/#sbcl - IRC Chatlog
Search
12:04:36
stassats
vm_prot_none doesn't help, but, OS_VM_PROT_WRITE does end up with Received signal 11 in non-lisp thread 9219342400, resignalling to a lisp thread.
12:56:53
stassats
pthread_join may be using a futex, so it wakes up the waiting thread, which destroys the stack and that futex call can't return?
13:17:07
stassats
and a test case: (loop repeat 1000 do (let ((sem (sb-thread:make-semaphore))) (loop repeat 10 collect (sb-thread:make-thread (lambda () (sb-thread:wait-on-semaphore sem)))) (sb-thread:signal-semaphore sem 10)))
13:24:40
stassats
https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/lib/libc/thread/rthread.c#L153
13:34:01
stassats
are we doing something wrong by freeing the stack after pthread_join? i don't know what other trigger to employ after which it's safe to free
13:37:22
stassats
how are other OSes do it? what did openbsd do before? is this only happening after the switch to futexes for sempahores?
13:55:08
stassats
i think i can try one last heuristic, is the value coming from a combination and that combination has no chance of being inlined
13:55:34
pfdietz
And is there a way to test if the property that transforms depend on is true? If nothing else, turning that on as a sanity check could find latent bugs.
14:26:55
stassats
one completely different solution, so i'm removing variables and change the order of LVAR writes, and stack-analyze doesn't like that