Run a job that the test suite with MSan to the CI - #158625
StanFromIreland wants to merge 4 commits into
Conversation
|
Note, |
| } | ||
| monitoring->local_monitors = (_Py_LocalMonitors){ 0 }; | ||
| monitoring->active_monitors = (_Py_LocalMonitors){ 0 }; | ||
| memset(monitoring->tool_versions, 0, sizeof(monitoring->tool_versions)); |
There was a problem hiding this comment.
That's a surprising change. Does the current code rely on uninitialized memory? If it's a legit bug, it should be backported.
There was a problem hiding this comment.
Please see PR description:
A little fix is included, allocate_instrumentation_data() now zeroes the tool_versions of a _PyCoMonitoringData, which update_instrumentation_data() previously read uninitialised. This doesn't have an affect in practice, as the garbage data only decides whether to clear some bits that are already zero, so the outcome is the same either way.
|
test_faulthandler seems to log SEGV from faulthandler_raise_sigsegv and log FPE from faulthandler__sigfpe_impl(). TSan is run with At least, skip_if_sanitizer_signal() of test_faulthandler can be updated to add return support.skip_if_sanitizer(f"TSAN/UBSan itercepts {signame}",
thread=True, ub=True, memory=True) |
Co-authored-by: Victor Stinner <victor.stinner@gmail.com>
We have to disable extension modules that link against system libraries (which are not built with MSan) since memory those libraries initialise is reported as uninitialised. While this does significantly reduce coverage of some modules, it saves a great amount of CI time. I also had to unpoison a few buffers filled by libc that MSan does not intercept.
A little fix is included,
allocate_instrumentation_data()now zeroes thetool_versionsof a_PyCoMonitoringData, whichupdate_instrumentation_data()previously read uninitialised. This doesn't have an affect in practice, as the garbage data only decides whether to clear some bits that are already zero, so the outcome is the same either way.Inspired by #158584.