Search
Saturday, 10th of November 2018, 0:26:53 UTC
0:28:59
stassats
something like 88a92a8129b6559c140e16e8d0e01bb7bba56f6a
0:34:15
stassats
it would be good to know what's the PC when that "type 6" sigsegv is delivered
0:41:53
joshe
it's the same as in the core dump, <futex+10>
0:42:42
stassats
well, it's in the main thread, the main thread shouldn't die, should it?
0:42:55
stassats
why is it starting from 1 and not 0?
0:42:57
joshe
if it's not in the initial thread then it must be in a thread struct which was unmapped after the thread finalized
0:43:44
joshe
I think that thread numbering is gdb's, the OS uses random pid-like IDs
0:44:54
stassats
gdb indeed starts from 1
0:45:13
stassats
so, there's no way thread 1 is being deallocated
0:48:01
stassats
a new message syscall [sbcl]83491/452323 sp 254937cd8 not inside 254748000-254938000
0:49:28
joshe
well I'm getting a trap, presumably the page fault from trying to retq with sp pointing to unmapped memory
0:50:26
joshe
how is that happening though, the sp value it's being killed for isn't even inside the main thread's stack
0:55:41
stassats
removed free_thread_struct(post_mortem);, can no longer crash in info.impure.lisp
1:00:49
stassats
we are calling pthread_join, so it shouldn't be existing anymore at all
1:00:53
stassats
before free_thread_struct
1:01:02
stassats
so, how come and why the main thread is receiving it?
1:07:27
stassats
well, i'm still puzzled and will leave it at that for today
1:12:28
joshe
this isn't happening in the main thread
1:12:50
stassats
well, duh, i never believed that anyway
1:13:23
joshe
the thread didn't make it into the core dump
11:14:07
stassats
what if instead of unmapping the thread struct i'll just vm_prot_none it
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:08:02
stassats
so, some OS thread is touching a thread corpse inappropriately
Saturday, 10th of November 2018, 12:26:53 UTC