Lenient Fiber.current access on segfault handler
#16612
Conversation
If the segfault handler is executed in a thread the runtime knows nothing, Fiber.current will be not initialized, leading to a GC allocation which is not allowed.
Co-authored-by: Julien Portalier <julien@portalier.com>
straight-shoota
changed the title
Fiber.current access on segfault handler
|
Something I noticed is that when a signal is raised from a worker thread of the gc, that is flagger as "No current fiber found while handling segfault. Probable unregistered thread" which is correct yet maybe misleading since the user is doing nothing wrong with threads necessarily in that situation. Not sure how to identify a worker thread programatically. I tried to get the threads' name but I got nothing... |
|
Perhaps we could check |
|
GC worker threads are not created by Crystal directly. They won't be in Thread.threads. I don't see how your idea leads to differentiate GC workers threads from other non-crystal created threads |
|
No I only want to differentiate Crystal threads which are expected to have a current fiber, and other threads (including ones from the GC) which don't. |
|
Is the message actually useful? I think it's more confusing that anything. |
3 participants
If the segfault handler is executed in a thread the runtime knows nothing, Fiber.current will be not initialized, leading to a GC allocation which is not allowed.
This is discovered in bcardiff/crystal-fswatch#5 (comment)
Without this changes an unknown thread, in this case it was one created in darwin via
dispatch_queue_createwill block:After this change we will get a crash with a stacktrace