Repository navigation
test(foundation): engine agreement module flakes on tshark crashes (TSharkCrashException, retcode 255) #1534
Description
tests/foundation/engines/test_engine_agreement_runtime.py (added in #1508) fails intermittently. tshark exits with retcode 255, and pyshark raises TSharkCrashException: TShark (pid N) seems to have crashed (retcode: 255).
The harness caches one run per capture, so a single crash fails every pyshark aspect of that capture: 9 ERROR != OK subtests.
Seen so far, always on a different capture, and never reproducing on a rerun:
- CI: fix(registry): unregistering a custom protocol removes its name from __proto__ (#1505) #1530's
PyPCAP/PyPCAPFile parity Python 3.11job (114060334917) failed onarp.pcap. fix(registry): unregistering a custom protocol removes its name from __proto__ (#1505) #1530 only changes registry code. - Locally: the test(foundation): reassembly, traceflow, engine and registry round trips (#1202) #1508 review hit it in 1 of 5 module runs, the fix(toolkit): pyshark TCP trace crashes because tshark 4.x reports flags as 'True'/'False' #1514 worker on
options-ipv4.pcap, and the fix(engines): pyshark engine counts a systemd Journal Export Block as a frame #1515 worker onoptions-ipv6.pcapin 1 of 4 runs.
Fix: retry a pyshark run once on TSharkCrashException before recording ERROR, and log the retry so a persistent crash still fails. Do not turn it into a skip.
Activity
JarryShaw commentedon Oct 9, 2026
More detail on the cause, from the #1527 worker. When this happens, asyncio logs
Unknown child process pid N, will report returncode 255. Something else in the process collected tshark's exit status before pyshark could, and pyshark reports that as a crash. The worker reproduced it on plainmainin 3 of 6 all-engine scripted runs; 184 standalone pyshark reads never crashed. The retry in #1536 handles the symptom, but the competing child-reaping is the likely root cause.test(foundation): retry a pyshark engine run once on a tshark crash (#…