tests: tolerate Python micro-version mismatch in capture headers

[tmsteph]

Summary

• Compare the capture header Python major/minor version rather than the exact micro/release bits, which can differ when the extension was compiled with a different interpreter micro release.
• Retain the full header shape check and add nine positive/negative compatibility cases.
• Addresses the failure reported in Debian bug #1146575.

Validation

• 15 targeted integration tests passed in an isolated Python 3.14.8 environment.
• Python syntax and git whitespace checks passed.
• Broader container run: 688 passed, 15 skipped, 18 failed (primarily native-tracing/attach environment or missing test dependencies); not claiming a clean full suite.

Signed-off-by: Thomas Stephens tmsteph@users.noreply.github.com

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.32%. Comparing base (060d7de) to head (70a12b2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1048      +/-   ##
==========================================
+ Coverage   92.31%   92.32%   +0.01%     
==========================================
  Files         103      103              
  Lines       13363    13381      +18     
  Branches      483      484       +1     
==========================================
+ Hits        12336    12354      +18     
  Misses       1027     1027              

Flag	Coverage Δ
cpp	92.32% <100.00%> (+0.01%)	⬆️
python_and_cython	92.32% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[godlygeek]

Hm, can you link to that Debian bug report? Is Debian is building the extension module with one interpreter and then testing it with a different one?

[tmsteph]

Thanks for checking. The Debian bug report is https://bugs.debian.org/1146575 . The mismatch reported is between the Python version encoded in the capture header (3.14.7) and the interpreter used when testing it (3.14.6). This does not by itself prove Debian compiled the extension using a different interpreter; it shows that the recorded and test-time micro versions differ. The patch continues to check the eight-digit header encoding and the major/minor version, while allowing a micro-version difference.

[godlygeek]

This does not by itself prove Debian compiled the extension using a different interpreter; it shows that the recorded and test-time micro versions differ.

What could cause that other than building Memray with one interpreter version and then running the tests with a different interpreter version?

[godlygeek]

I do think there's a Memray bug here, actually - I think we meant to record the version of Python that the capture file was generated with, not the version of Python that the Memray module was compiled with. I'll make sure we're not doing this intentionally, and fix it if not.

But separately from that, I'm pretty convinced there's some issue on the Debian side here - is it intentional that you built Memray with Python 3.14.7 but ran the tests with Python 3.14.6? I'd really expect you to use the same Python version (presumably the newly built Python version) to both build Memray and run its test suite.

[godlygeek]

Closing in favor of #1055