scripts/test.sh hangs indefinitely at the venue-parity contract when ImageMagick is installed (bash runs generate-sbom.py, 'import' becomes ImageMagick)

[OmerZeyveli]

Version: main (d698db8e) · Platform: Ubuntu 24.04, x86_64, gcc 13.3

What happens

scripts/test.sh hangs forever at Step 0j on any machine that has ImageMagick installed. No error, no timeout — the process just sleeps indefinitely, after printing:

=== Step 0j: venue parity contract (one harness, every venue) ===
venue-parity contract OK (22 workflows marker-checked, 10 venue workflows whitelist-walked, 4 deliberate step exemptions)

Root cause

tests/test_venue_parity_contract.sh probes every entry point with bash:

for entry in $HELP_ENTRIES; do
    out=$(cd "$ROOT" && bash "$entry" --help 2>&1) && rc=0 || rc=$?

HELP_ENTRIES contains one Python file, scripts/ci/generate-sbom.py. Running it under bash makes the shell interpret Python source as shell commands, so the module imports become commands:

$ ps -o pid,cmd -p 2153369
2153369 import datetime

On Linux import is ImageMagick's screen-capture tool, which blocks waiting for the user to click a window:

$ command -v import
/usr/bin/import
$ import --version
Version: ImageMagick 6.9.12-98 Q16 x86_64

So the probe waits on an X11 window selection that will never come. </dev/null does not help — import waits on the display, not stdin.

CI almost certainly does not hit this because container images generally lack ImageMagick. It reproduces reliably on a desktop Linux developer machine, which is exactly where CONTRIBUTING tells contributors to run scripts/test.sh before submitting.

Minimal reproduction

bash scripts/ci/generate-sbom.py --help     # hangs forever with ImageMagick installed

A second, quieter consequence

Because the probe has always run this file under bash, the contract has never actually verified generate-sbom.py's --help behaviour — it has only ever checked bash's misinterpretation of it. Under the correct interpreter the script does satisfy the contract:

$ python3 scripts/ci/generate-sbom.py --help
Generate the release SPDX SBOM (sbom.json).
...
$ echo $?
0

(generate-sbom.py:22 handles -h/--help and exits 0.)

Suggested fix

Choose the interpreter by extension rather than assuming bash. Note generate-sbom.py is not executable (-rw-rw-r--), so invoking ./"$entry" directly would fail on permissions — the interpreter has to be explicit, or the exec bit added:

 for entry in $HELP_ENTRIES; do
-    out=$(cd "$ROOT" && bash "$entry" --help 2>&1) && rc=0 || rc=$?
+    case "$entry" in
+    *.py) probe_runner=python3 ;;
+    *)    probe_runner=bash ;;
+    esac
+    out=$(cd "$ROOT" && "$probe_runner" "$entry" --help 2>&1) && rc=0 || rc=$?

The same applies to the STRICT_ENTRIES loop below it, which currently happens to contain only shell scripts — worth guarding anyway so a future .py entry does not reintroduce this.

Happy to send a PR if useful.

[OmerZeyveli]

Correction to my own report — the diagnosis holds but my suggested patch did not match the code, and the real bug is smaller and more specific than I described. Apologies; I had read a truncated view of the loop.

HELP_ENTRIES already handles .py. The problem is that the bash probe runs first and unconditionally, and its result is then thrown away for .py entries:

for entry in $HELP_ENTRIES; do
    out=$(cd "$ROOT" && bash "$entry" --help 2>&1) && rc=0 || rc=$?   # <-- runs for .py too
    case "$entry" in
    *.py) out=$(cd "$ROOT" && python3 "$entry" --help 2>&1) && rc=0 || rc=$? ;;
    esac

So for generate-sbom.py the script is executed twice: once under bash (whose output is discarded) and once under python3 (which is the one that counts). The discarded bash run is what spawns import datetime → ImageMagick → indefinite hang, so the python3 line is never reached.

That makes the fix a one-line restructure rather than a new case: only run bash when it is actually the right interpreter.

 for entry in $HELP_ENTRIES; do
-    out=$(cd "$ROOT" && bash "$entry" --help 2>&1) && rc=0 || rc=$?
     case "$entry" in
     *.py) out=$(cd "$ROOT" && python3 "$entry" --help 2>&1) && rc=0 || rc=$? ;;
+    *)    out=$(cd "$ROOT" && bash "$entry" --help 2>&1) && rc=0 || rc=$? ;;
     esac

Everything else in the report stands: the hang reproduces with bash scripts/ci/generate-sbom.py --help on any machine with ImageMagick installed, ps shows the stuck import datetime, and python3 scripts/ci/generate-sbom.py --help exits 0 with a Usage: line as the contract requires.

One consequence worth noting: because the bash result is overwritten for .py entries, this has been dead work rather than a wrong assertion — the contract's verdict for generate-sbom.py was always the python3 one. The only damage is the hang.

[OmerZeyveli]

Context on why I am not opening a PR for this yet, plus a separate observation you may want to know about.

I have the one-line fix from the comment above working locally, with before/after evidence:

	exit	wall
before	124 (30s timeout)	never returns
after	0	< 1s

and interface probes OK (18 --help entries, 8 strict-flag entries) now prints — a line that was previously unreachable because the script hung before it.

But I cannot claim make -f Makefile.cbm test passes, because it does not pass on main here before any change.

main fails 10 tests on this machine

6817 passed, 10 failed, 4 skipped

tests/test_subprocess.c:510  subprocess_quiet_timeout_kills_ignoring_tree   ASSERT(ready)
tests/test_cli.c:904         install_rc == 1, expected 0
tests/test_cli.c:952         rc == 1, expected 0
tests/test_cli.c:1018        rc == 1, expected 0
tests/test_cli.c:1107        fake.mutation_reserve_count == 0, expected 1
tests/test_cli.c:1314        ASSERT(binary_published)
tests/test_cli.c:1642        rc == 1, expected 0
tests/test_cli.c:1705        fake.mutation_reserve_count == 0, expected 1
tests/test_cli.c:3961        agent uninstall refusal must fail before removing the live binary
tests/test_cli.c:3503        cli_install_copies_binary_to_target_issue472: rc == -1, expected 0

The nine test_cli.c failures share a symptom — the installer refuses to stage:

error: failed to stage install candidate: activation transaction I/O failed
error: failed to stage install candidate: activation transaction I/O failed: target-entry-snapshot (os 0)

What I ruled out

• Not my change. tests/test_venue_parity_contract.sh is a standalone shell script; no tests/*.c references it, so it is not part of the C test-runner. The failures reproduce on unmodified main.
• Not a group-writable checkout. My first guess was the activation transaction's source-directory policy, since my working copy sat under a 0775 parent. I re-cloned to a path whose entire ancestor chain is 0755/0750 and re-ran: identical 10 failures. So that hypothesis is wrong.
• Not a single bad clone. Reproduced on two independent clones of main at different commits (d698db8e and 27893016).

I did not chase it further — the tests install into /tmp, which is 1777, and I wondered whether the same directory policy rejects a world-writable staging parent, but I did not verify that and am not asserting it.

Environment: Pop!_OS 24.04 LTS (Ubuntu 24.04 base), x86_64, 8 cores, gcc 13.3.0, make -f Makefile.cbm test.

Question

Is a green make test expected on a Linux workstation, or do these nine install tests need something the environment here lacks (a container, a particular TMPDIR, root)? If the former, this looks like a second bug worth its own issue and I am happy to open one with the full log. If the latter, it might be worth a line in CONTRIBUTING, since it currently tells contributors to run the suite locally before submitting.

Either way, happy to send the venue-parity fix as a PR whenever you want it — I just did not want to claim a passing suite I could not observe.

[DeusData]

Thank you for separating the ImageMagick hang from the unrelated suite failures, and for correcting the first patch description. A green make -f Makefile.cbm test is expected on a normal supported Linux workstation; the project runner invokes that target directly and it should not require root, a container, or a special TMPDIR.

Please open the ten suite failures as a separate issue with the full failing output, TMPDIR, umask, and the mount type/options for the temporary filesystem. The nine activation-transaction failures appear to be one family, while the subprocess failure may be separate. For the venue-parity fix, your focused before/after evidence is sufficient: a PR can state that the full suite is blocked by the separately reported pre-existing failures rather than claiming it is green. We would welcome that focused PR. Thank you for being precise about what you could and could not verify.