[benjamindehli]

Three times the Linux pluginval step has passed every test and then crashed while pluginval shut down, with glibc reporting heap corruption: in thread-local storage on 5 October, in the run loop on 24 October, and in XCloseDisplay on the zoom pull request today. Each time a re-run was green. glibc only notices damage when memory is freed, so these crashes cannot say whose write did it, and each one cost a re-run and some doubt.

I built the release branch as a VST3 with the address and undefined behaviour sanitizers across the plugin and JUCE, and ran pluginval against it ten times: six with the pinned seed, three with random seeds and one with leak checks on. Every run passed all 25 test groups with no sanitizer reports and no leaks. So the crash is pluginval and Xlib shutting down on the runner, not the plugin.

A weekly sanitized pluginval job

A new job, "pluginval, sanitized", builds the VST3 with the sanitizers and runs pluginval against it twice, with the pinned seed and with a random one, and fails on anything the sanitizers report. It stops at the first bad write, so if the plugin ever does damage memory, it names the line. It runs on the weekly schedule and when started by hand, since the sanitized build takes most of the hour.

A crash after SUCCESS passes with a warning on Linux

The Linux pluginval step now keeps its output. If pluginval exits with an error after printing SUCCESS, and no test failed, the step passes and prints a warning that points at the stack. A failed test, or a crash before SUCCESS, still fails it. pluginval also starts its warnings with !!!, so the check looks for its actual failure markers.

The fetch is shared

Both jobs need pluginval, so the fetch step moved unchanged into .github/scripts/fetch_pluginval.sh, and the pinned version and the three checksums are written down once. .gitattributes already keeps .sh files with LF endings on the Windows runner.

What changes for contributors

• A Linux crash in pluginval's shutdown no longer blocks a merge, and shows as a warning.
• The weekly run includes a sanitized pluginval run, and it can be started by hand.
• CONTRIBUTING describes both, with the commands to run the sanitized check locally.

How it was checked

• The ten sanitized pluginval runs above. I also checked that the sanitizer was really active: without its runtime preloaded, the plugin refuses to load.
• The new validate logic, run as written in the workflow against five prepared logs with stand-ins for xvfb-run and gdb. A clean run passes. A crash after SUCCESS passes with the warning, also when pluginval printed a warning first. A failed test and a crash before SUCCESS fail with their own exit codes.
• The fetch script, run on a Linux setting: it downloads v1.0.4 and the checksum matches.
• The workflow parses, every run block passes bash -n, and prettier and the counts and structured data checks pass.

Anything I am unsure about

How long the sanitized build takes on a runner. Locally it took about 15 minutes at three jobs, and the job has a 60 minute limit. I started it by hand on this branch to see before merging.