test: sort the remaining GraalPy-only failures into defects and gates

These GraalPy-only failures remain on the experimental leg at b2cd14078, apart from #1959 and #1960. They need sorting into defects and gates before GraalPy can be promoted (#1958, decision D):

Possibly a real defect: test_io_seekable_reader_short_reads_1586_unit::test_end_of_stream_reads_ahead_only_as_far_as_asked returns data from offset 14 after seek(0) in most runs. Reproduce it on GraalPy first.
MultiDict(MultiDict) gives [[5, 6]]. GraalPy's dict.__init__ appears to call the overridden __setitem__ (inferred, not yet confirmed). An explicit dict.__setitem__ at pcapkit/corekit/multidict.py:139 may fix it.
Interpreter limits that need a GraalPy skip gate in the test:
- pickle protocols 0 and 1 fail with typing.Generic() takes no arguments;
- struct.calcsize rejects large counts, and so does an int too large for a Java int;
- preexec_fn is unsupported, which breaks the test_vendor_test_gate_1853 tests;
- socket.SOCK_SEQPACKET, resource.setrlimit and _abc_impl are missing.
Speed: the leg stops at its 110-minute timeout with about 62% of the tier done. The slowest tests run 280–530 s each: PCAPNGTruncatedFileTests, test_tier_guard_xdist, test_ipv6_exthdr_cut_rebuild_unit.

The evidence and job ids are in the fail-green audit behind #1958.

Blocked until the #1958 phase-1 PR lands, since that PR re-tiers these test modules.

test(corekit): keep only the cases that fail without the GraalPy fixes (

fix(corekit): upgrade the MultiDict port to werkzeug 3.1.9 (#1963)

Why the GraalPy leg runs out of time. I read main's last three GraalPy jobs (118448241345, 118333963843, 118418528737).

Mostly a hang, not slowness. A blocking flock in the tier-guard lock self-deadlocks on GraalPy and freezes the whole xdist session: 71 minutes with no output on 217224e70. Filed as test: the tier guard's blocking flock deadlocks GraalPy's xdist session #1977, worker on it.
Still too long without the hang. The run that did not stall reached 76% in 5729 s, which projects to about 126 minutes against the step's 110-minute timeout.
Worker deaths are heap exhaustion, not test failures. All are node down: Not properly terminated at 2.4–2.7 GiB RSS, against --vm.Xmx2g with ExitOnOutOfMemoryError. This is inferred: the JVM message is not in the log.
GraalPy already runs only the ALL tier, the same selection as every CPython leg.

Next, after #1977:

Skip the two nested-pytest probes (XdistSubprocessTests, ProbeWorkerCrashTests) on GraalPy. They idle the other workers for 5–13 minutes.
Shard the GraalPy leg in two, about 63 minutes each.
Try a 2.5 GB heap.

Question for you (ruling E, #1958): ALL holds every unit module that imports pcapkit, about three quarters of them, not a minimal tailored set. Should ALL be trimmed to a curated core for the non-latest legs? That would shorten every leg, not only GraalPy.

The #1977 fix worked on main's first GraalPy run after it (job 118541324140, 7f7c7cf8b). The session never stalled: the longest gap between progress lines was 249 s, against 71 minutes before. It reached 92% before the 110-minute timeout, with 3334 passed, up from 1338.

What remains is plain slowness. 17 xdist workers went down from heap exhaustion, and 83 tests failed, worker crashes included. The next levers are the ones listed above: take the nested-pytest probes off GraalPy, shard the leg, and try a 2.5 GB heap. They still wait on your answer to the ALL-size question.

test: give the finaliser backstop tests GraalPy's gc.collect grace (#…

test: flush GraalPy's inline caches before judging collectability (#1963

I re-measured on main f96a6b156, which includes #2012 (shards) and #2013 (inline-cache flush). The graalpy-25.4 leg (job) now runs every shard to completion, with no out-of-memory exit, in about 46 min of test time. The only failures are two tests, each with its own root cause:

GraalPy: bytearray for the c format is not refused (test_fields_bytearray_pack_2004) #2015: on GraalPy, packing a bytearray for the c format is not refused (test_fields_bytearray_pack_2004_unit).
GraalPy: collect_until's late-finaliser test outruns its 5 s grace #2016: collect_until's late-finaliser test runs past its fixed 5 s grace (test_extraction_ownership).

Workers are on both now. Once they land, the next main run is the green measurement for this issue.

main 2ab2260c9 ran the graalpy-25.4 leg green (job). It now includes #2012 (shards), #2013, #2017 (#2016) and #2018 (#2015).

Every shard ran to completion. There were no failures and no out-of-memory exit, and the step exited 0.
Test time totalled about 55 min.

That leaves no GraalPy-only failures to sort, so I'm closing this as completed. Promoting GraalPy is the remaining step, and it belongs to #1958.

ci: run PyPy's shards through util/pytest_shards.py (#2005, #1963)

fix(ci): run GNU timeout in the experimental tests step on any image (#…

ci: run PyPy's shards through util/pytest_shards.py (#2005, #1963)

fix(ci): run GNU timeout in the experimental tests step on any image (#…

ci: run PyPy's shards through util/pytest_shards.py (#2005, #1963)

ci: run the curated ALL tier on PyPy, split into separate pytest runs (…

Navigation Menu

Repository navigation

test: sort the remaining GraalPy-only failures into defects and gates #1963

21 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

test: sort the remaining GraalPy-only failures into defects and gates #1963

Description

Activity

JarryShaw commented on Oct 20, 2026

JarryShaw commented on Oct 20, 2026

21 remaining items

JarryShaw commented on Oct 21, 2026

JarryShaw commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions