RAI: do not prepend thread ID to backtraces from signal handler context

[kpamnany]

PR Description

Ctrl+T sends a SIGINFO (on Mac, SIGUSR1 on Linux) to Julia which triggers a backtrace. RAI Julia prepends [signal (X)] thread (Y) to backtraces. But in signal handler context, there is no "current task" from which to get the thread ID.

This PR fixes the problem by checking to see if we're in signal handler context before calling jl_threadid().

Checklist

Requirements for merging:

• I have opened an issue or PR upstream on JuliaLang/julia: N/A--this fixes a RAI patch
• I have removed the port-to-* labels that don't apply.
• I have opened a PR on raicode to test these changes: https://github.com/RelationalAI/raicode/pull/19065

[NHDaly]

🤔 wasn't the whole point of these thread-ids to make it easier to read segfaults when there are multiple threads? Those are also signal handlers, right?

(Did we never end up up-streaming that change?)

[kpamnany]

🤔 wasn't the whole point of these thread-ids to make it easier to read segfaults when there are multiple threads? Those are also signal handlers, right?

Yes. But SIGSEGV and SIGBUS have a different signal handler function and that checks jl_current_task and takes an alternate path if it is NULL.

Ctrl+T is handled by the signal listener function, which directly dumps a backtrace here.

I tried checking jl_current_task the same way segv_handler does but it was 0xfffff...fe rather than NULL. That's because jl_current_task uses container_of on jl_get_pgcstack (which gets thread-local data) and container_of uses offsetof and NULL minus some offset will give you 0xfffff...<something>. I do not know why checking jl_current_task directly works for segv_handler.

In the process of writing this up, I found jl_get_current_task() which is better to use than jl_get_pgcstack() so I'll push that fix shortly.

(Did we never end up up-streaming that change?)

We did not. Jameson wanted the task pointer to be prepended instead of the thread ID and we never got around to arguing it. Edited to add: upstream issue is here.

[NHDaly]

Cool, thank you for the explanation! 👍

I don't see anything wrong with printing the task_id instead, if that's what jameson prefers? We just wanted to be able to separate the logs, i think?