Repository navigation
Python 3.15 produces incompatible Jitdumps on MacOS #150723
Description
Bug report
Bug description:
See: mstange/samply#826 and mstange/linux-perf-data#27
Reproduction with samply
fib.py:
def fib(n):
if n < 2:
return n
return fib(n - 1) + fib(n - 2)
print(fib(36))Works: Just using the perf-map resolves py::fib:
PYTHONPERFSUPPORT=1 samply record -- python3.15 fib.pyHowever, when emitting the jitdumps, we see a ton of unresolved 0x... frames and no py::fib:
PYTHON_PERF_JIT_SUPPORT=1 samply record -- python3.15 fib.pyThe issue
CPython 3.15 introduces Jitdump support on MacOS: #136461
This PR also changed the struct layout:
cpython/Python/perf_jit_trampoline.c
Lines 220 to 224 in f31a89b
#if defined(__APPLE__)
uint64_t thread_id; // Thread ID where code was generated
#else
uint32_t thread_id; // Thread ID where code was generated
#endif
This is not compatible with the original linux perf data specification, which almost all profilers/tools rely on. I highly recommend fixing this, otherwise profilers won't be able to take advantage of jitdumps.
CPython versions tested on:
3.15
Operating systems tested on:
macOS
Activity
canova commentedon Jun 1, 2026
Thanks a lot for filing this bug! This is indeed a problem, and I was just typing an issue message for this.
Jitdump support on macOS was implemented in #136461.
While I was working on that PR I changed this jitdump struct to hold a
uint64_tvalue forthread_idon macOS.This was due to the fact that
pthread_threadid_npreturneduint64_tinstead ofuint32_t. It's captured here:cpython/Python/perf_jit_trampoline.c
Line 655 in f31a89b
But this was wrong! jitdump file format specifically mentions that this has to be
uint32_t:https://github.com/torvalds/linux/blob/e43ffb69e0438cddd72aaa30898b4dc446f664f8/tools/perf/Documentation/jitdump-specification.txt#L74
So we need to force macOS to also store
uint32_tas well to keep the layout same. Samply's author @mstange mentioned that thisthread_idis not used for anything: mstange/linux-perf-data#27 (comment) So we can just truncate theuint64_tvalue that we get.cc @pablogsal
canova commentedon Jun 1, 2026
I was working on a patch locally and realized that this fix alone is not enough. It looks like there is a secondary issue.
It looks like it's because of the timestamp domain mismatch. Currently python records the jitdump timestamps with
clock_gettime(CLOCK_MONOTONIC). On Linux that's fine because the consumers (perfandsamply) timestamps its samples withCLOCK_MONOTONICtoo, so the records and samples share a clock.On macOS though,
samplytimestamps its samples withmach_absolute_time(). Those are different clock domains:CLOCK_MONOTONICkeeps advancing while the machine is asleep,mach_absolute_time()does not. For example, on my machine they differ by ~28 days of accumulated sleep. That's why we have to use
mach_absolute_timealso on the python side when we are recording our jit dump records on macOS.Currently other jitdump producers like SpiderMonkey, v8, JavaScriptCore, etc. all output their timestamps with
mach_absolute_timeon macOS. So I think it makes sense for python to align there as well.TBH, I should have tested this code path more properly. I was mostly focusing on
PYTHONPERFSUPPORTand neglectedPYTHON_PERF_JIT_SUPPORT. Sorry about that!gh-150723: Fix perf jitdump files on macOS (#150728)
[3.15] gh-150723: Fix perf jitdump files on macOS (GH-150728) (#150832)