[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort): mypy and isort are clean on common.py; pylint adds nothing new except the existing too-many-statements on make_dumper, now 85 statements against 65 before
• make test passes, and a test case covers the change: see below for the modules and legs actually run
• Added a changelog entry: N/A, added centrally

What is the purpose of your pull request?

• fix — corrects a defect

---

Closes #1372

First bad commit: 9093061b3 (#1305). Found with git bisect run from 13aa677be (bad) back to 11ae68ebf (good), running the foundation leg with a 50 MB file cap. #1335 and #1336 are not the cause.

Root cause. In the plain-unittest leg, the default run at test_extraction_record_header_unit.py:63 ends up with an Ethernet info object (pcapkit.protocols.data.link.ethernet.Ethernet) whose class does not match the dumper's Info. That is cross-import pollution. So object_hook never matches it and the object goes to _append_fallback. Its vars() include __next_type__, which is a protocol class.

Before #1305, vars(cls) was a mappingproxy that was written out with str(). #1305 changed this to new_value.update(vars(value)), so every class became a real dict and was expanded. That walks typing generics, schemas, fields, enum types, int and the descriptors of each.

Nothing is memoised, so every shared node is expanded again on every path to it. Output therefore grows exponentially while the stack stays shallow. At 3,000 fallback calls the stack was 64 frames deep against a recursion limit of 1,000, and wrapper_descriptor had been expanded 931 times. That is why no RecursionError was raised.

Fix (pcapkit/dumpkit/common.py).

• A class, module or routine is written as its qualified name. That alone removes the blow-up.
• An object already on the current expansion path is written as <circular reference: T>, so a cycle terminates. A shared object that is not part of a cycle is still written in full every time it appears, so no data is dropped.
• Safety net: if one top-level fallback object expands into more than FALLBACK_LIMIT = 10_000 objects, the dumper raises UnsupportedCall instead of writing a marker. Every fixture stays far below that: across the foundation, dumpkit and interface legs no fallback object expands into more than 7, so the budget never fires on a fixture.

These rules depend on no particular engine. Schema change: a class, module or function in fallback output is now written as its name.

Second issue. test_runtime_engines was wrong, not the code. #1305 passes version= on purpose (#1255), so the test now expects version=VersionInfo(2, 4).

Evidence (all runs under ulimit -f 204800):

• New tests/dumpkit/test_fallback_cycle_unit.py: 4 passed. With origin/main's common.py restored, 3 fail (cycle and class: RecursionError; budget: nothing raised). The shared-object test passes there too, as it should: it pins that nothing is lost.
• util/run_unittest_leg.py foundation: 483 test(s), 0 failure(s), 0 error(s). On main it was 2 failure(s), 2 error(s), Errno 27. Within the leg, out.json is now at most 25,767 bytes.
• util/run_unittest_leg.py dumpkit: 220 test(s), 0 failure(s), 0 error(s).
• pytest: test_runtime_engines 5 passed, test_extraction_record_header_unit 10 passed, test_common_unit 14 passed, test_dumper_roundtrip_unit 7 passed, tests/project 389 passed and 1 skipped.

[JarryShaw]

Cross-review verdict on eabeaab6d: NEEDS CHANGES — one design point (Sonnet reviewed; author Opus). The reviewer rated this a nit; I am making it blocking because of the owner's #1266 ruling that JSON and plist stay the round-trip formats.

The seen memo drops data. A shared but non-cyclic object inside a fallback value is written in full once, then as <repeated reference: T> on every later appearance — and the PR's own test pins that. The blow-up came from walking classes' attribute tables, and rendering classes/modules/functions as qualified names removes it by itself. So keep cycle detection on the current path only, expand repeats in full, and drop seen. If a safety net is still wanted, make it an explicit size or depth budget that raises a clear in-library error rather than silently substituting a marker.

Everything else held:

• Cause confirmed: swapping only common.py between 9093061b3^ and 9093061b3 flips test_runtime_engines + test_extraction_record_header_unit from 15 OK to 2 Errno 27 errors. With logging, Ethernet/IPv4/TCP info reach the fallback only after a purging module (test_runtime_engines, registry/test_foundation, engines/test_engine_base) has run.
• No real capture hits a marker: 22 fixtures × 4 engines × json/plist = 176 files, byte-identical to main; even in a simulated polluted mode, no <circular or <repeated appears in any of them.
• The tracker is safe: state lives on self, and the resets are in finally.
• Tests: the version=VersionInfo(2, 4) test fix is right (fix(dumpkit): pcap output drops the input's global-header version #1255). The new test fails 3 on main's common.py. foundation leg 483/0, dumpkit 219/0, tests/project 389.

The re-import pollution that sends real Info objects to the fallback is out of scope here; I will file it with #1332's findings.

[JarryShaw]

Round-2 verdict on b89db1461: GOOD TO GO (Sonnet reviewed; author Opus). Round 1's data-loss concern is resolved.

• Path-only cycles behave correctly. Self-, 2- and 3-cycles get <circular reference: T> where the object meets itself. In a diamond (A→B, A→C, B→D, C→D), D is written in full twice with no marker. Shared pairs under sibling branches expand identically. The path entry is popped in finally, and both counters are reset after a raise.
• No data lost. Json and plist dumps of 23 captures under the default, dpkt and scapy engines (138 files) are byte-identical to main. In the leg-polluted mode, main still hits RecursionError on arp.pcap and fills the cap on ipv4.pcap. This PR completes every run, and its output is a strict superset with classes shown as qualified names. No marker appears in any fixture dump.
• The budget never fires. 30,000 top-level objects in one container do not raise, and a single 2¹⁵-node expansion does. The re-measured peak over 23 captures × 3 engines × json/plist × 3 modes is 13 expansions, against a limit of 10,000. The FALLBACK_LIMIT comment's "no more than 7" should say 13.
• Tests and legs. foundation runs 483 tests with 0 failures, so all three of fix(dumpkit): JSON output of DPKT/Scapy frames grows without bound and fills the disk #1372's failures now pass. dumpkit gives 220/0 and tests/project 389. The largest out.json seen across the legs is 369 KB. The revert proof gives 3 failed and 1 passed; the passing test is the shared-object guard, as expected.

Nit, worth a follow-up: UnsupportedCall subclasses AttributeError, so hasattr and getattr(..., default) swallow the budget error; the reviewer demonstrated hasattr returning False. A ValueError-based class would fit better; json raises ValueError for circular input.

[github-actions]

Coverage: 88.98% (unit tier, Python 3.14, b89db1461, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18777	1032	2348	843	90.27%
pcapkit/corekit	1949	84	606	20	94.91%
pcapkit/dumpkit	225	2	80	2	98.69%
pcapkit/foundation	2443	102	852	39	94.39%
pcapkit/interface	112	7	40	5	92.11%
pcapkit/protocols	16013	206	4178	177	98.06%
pcapkit/toolkit	539	74	168	3	84.58%
pcapkit/utilities	429	4	122	4	98.55%
pcapkit/vendor	4409	2359	1006	158	42.84%

Per-file detail: the coverage-html artifact of this run.