|
From: Douglas K. <do...@go...> - 2019-01-15 01:50:58
|
Has anyone besides me seen this? It doesn't look particularly fun to track
down. Worst case, we don't need a balanced tree structure to find which
thread some memory belongs to - just go back to what we had - but I kind of
like that finding a thread stack from an address isn't linear in the number
of threads. Additionally, I was hoping that the Lisp data structure was
simple enough to share with the C code which would speed up
is_in_stack_space(), which is currently only used in a debugging way. But
if it doesn't work, that's kind of a problem, isn't it.
Unhandled SB-INT:BUG in thread #<THREAD #<error printing a THREAD:
Backtrace for: #<THREAD #<error printing a THREAD: #<JOIN-THREAD-ERROR
{10019C0003}>>
0: (SB-THREAD::NOTE-STACK-RANGE #<THREAD #<error printing a THREAD:
#<JOIN-THREAD-ERROR {10019C3833}>> #S(SB-IMPL::TREAP-NODE :KEY
139683444948992 :DATA (139683447046144 . #<THREAD "reader 1" RUNNING
{1001A61B93}>) :LEFT #S(SB-IMPL::TREAP-NODE :KEY 139683431350272 :DATA
(139683433447424 . #<THREAD "finalizer" RUNNING {1001668053}>) :LEFT NIL
:RIGHT NIL :PRIORITY 2547871647727447099) :RIGHT #S(SB-IMPL::TREAP-NODE
:KEY 139683451600896 :DATA (139683453698048 . #<THREAD "main thread"
RUNNING {1001688103}>) :LEFT NIL :RIGHT NIL :PRIORITY 1193941380623146742)
:PRIORITY 3609860409262339180))
|