prepend signal number and thread ID on backtraces #54380
Conversation
d-netto
force-pushed
the
dcn-prepend-sigid-and-tid-on-backtraces
branch
2 times, most recently
from
62870e7
to
9230640
Compare
d-netto
force-pushed
the
dcn-prepend-sigid-and-tid-on-backtraces
branch
from
fa1bf20
to
37b4410
Compare
d-netto
force-pushed
the
dcn-prepend-sigid-and-tid-on-backtraces
branch
from
37b4410
to
1a0a83d
Compare
| } | ||
| // do not call jl_threadid if there's no current task | ||
| if (jl_get_current_task()) { | ||
| ctid = jl_threadid() + 1; |
There was a problem hiding this comment.
This function is called from jlbacktracet(jl_task_t *t) which may be a task that is not on the current thread.
See jl_print_task_backtraces.
For profiling we store this information as metadata on the backtrace.
| ctid = jl_threadid() + 1; | ||
| } | ||
| snprintf(pre_str, 64, "thread (%d) ", ctid); | ||
| jl_print_native_codeloc(pre_str, (uintptr_t)ip); |
There was a problem hiding this comment.
This may be more confusing than helpful. It is not guaranteed that the ip is currently executed on the current thread?
|
Can you show some examples where this is useful and how the format ended up? |
|
This is how we're currently solving #51056. You can see what it looks like in #51659. The thread ID prefix is simply to help disambiguate stack traces if they're reported concurrently. It is not informational, i.e. it isn't intended to be the thread ID on which the stack trace was gathered (which is not especially useful information anyway). Jameson suggested using the task pointer instead but I feel that is even less useful. |
Now that I think about it, it would be useful information. We'll look into #41742, thanks for the pointer! |
tecosaur
added
display and printing
These extra information on the backtraces proved useful for us when filtering which servers failed due to a segmentation fault, for instance, and when diagnosing crashes in production more in general.