You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two types of stack frames: instruction pointers (to either C code or generated Julia code) and interpreter frames (Julia code being interpreted at runtime).
Problem
Interpreter frames only show up as unknown in CPU and allocation profiles.
Underlying issue
The backtrace buffers used by the CPU and Alloc profilers aren't GC roots, so the objects they point to (interpreter frames) can get garbage collected before a profiler user deferences them while decoding the profile. If you're not careful, this segfaults the process.
The CPU and alloc profiler currently sidestep this problem by using the StackTraces.lookup function to decode stack frames from raw backtrace buffers, which falls back on returning this "unknown" frame when it sees an interpreter frame:
isempty(infos) &&return [StackFrame(empty_sym, empty_sym, -1, nothing, true, false, pointer)] # this is equal to UNKNOWN
These don't seem to occur to frequently in practice, so we've gotten by without truly solving this problem.
Possible fix
In another memory profiling PR (#33467), @maleadt solved this problem by modifying the garbage collector's mark phase to find these pointers in backtrace buffers, thereby preventing them from being collected. Perhaps that change can be merged separately, so then both the allocation and CPU profilers can use reformat_bt, and include interpreter frames.
The text was updated successfully, but these errors were encountered:
For more information, I think these interpreter frames currently show up as unknown in the profiles collected via the Profile package. This issue is about teaching the Profiler to understand the interpreter frames in the stack traces it samples, so that it can report the frames being interpreted, instead of unknown. 👍
Background
There are two types of stack frames: instruction pointers (to either C code or generated Julia code) and interpreter frames (Julia code being interpreted at runtime).
Problem
Interpreter frames only show up as
unknown
in CPU and allocation profiles.Underlying issue
The backtrace buffers used by the CPU and Alloc profilers aren't GC roots, so the objects they point to (interpreter frames) can get garbage collected before a profiler user deferences them while decoding the profile. If you're not careful, this segfaults the process.
The CPU and alloc profiler currently sidestep this problem by using the
StackTraces.lookup
function to decode stack frames from raw backtrace buffers, which falls back on returning this "unknown" frame when it sees an interpreter frame:julia/base/stacktraces.jl
Line 109 in 0064663
These don't seem to occur to frequently in practice, so we've gotten by without truly solving this problem.
Possible fix
In another memory profiling PR (#33467), @maleadt solved this problem by modifying the garbage collector's mark phase to find these pointers in backtrace buffers, thereby preventing them from being collected. Perhaps that change can be merged separately, so then both the allocation and CPU profilers can use
reformat_bt
, and include interpreter frames.The text was updated successfully, but these errors were encountered: