vwemirror/RP412
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The podium survives a full page heap, four pods deep

Browse Source 
First run of this rig that was actually holding the instrument it claims.
Four pods under real full page heap - flags 0x3 in every cdb log, set by
elevated gflags, not the PEB trick that has stopped working - driven hard
enough to score 553..997, podium on.

Everything the diagnosis points at ran: four placed on the stand, the local
pod given its exterior (the podium's second MakeEntityRenderables pass, which
is the path the dumps finger), the full Application::Shutdown teardown, four
clean exits. No exception on any pod.

That is worth more than the earlier clean runs by some distance. Full page
heap traps a double free at the second free AND an overrun at the guard page,
in the culprit's own stack rather than in the victim's. Neither fired. So on
four pods over loopback with one teardown each, this bug does not happen.

It also settles the address-space question the rig kept running into: 2 works,
4 works, 6 dies. The population that actually crashed and the instrument that
would catch it cannot be had at the same time on one machine.

Left to try, in order of what is cheap: repetition, because a single sample of
an intermittent fault is nearly nothing; then three real machines, where the
podium and its teardown land at genuinely different moments per pod instead of
loopback's near-simultaneous nothing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-08-14 10:13:29 -05:00
co-authored by Claude Opus 5
parent 021ad36951
commit 74948fdd10
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
tools/podium-repro/README.md
+24
View File
@@ -223,6 +223,30 @@ exits, no exception. Then the cdb logs turned out to carry no
weaker even than the earlier light-page-heap ones. Its only value is as one
more sample of the crash failing to happen on its own.
**2026-08-14, FOUR pods, FULL page heap (`flags 0x3`), driven, podium ON:
no crash. This is the first properly instrumented negative.** Everything the
diagnosis points at ran and survived: `WinnersCircle: 4 placed on 8 spots`,
`own vehicle given an exterior` (the podium's second
`MakeEntityRenderables` pass on the LOCAL pod), full `Application::Shutdown`
teardown, four clean exits, no exception on any pod. Scores 553..997 - pod D
at 553 means real collisions and damage, not a parked field.
This is the run all the earlier ones were pretending to be. Full page heap
traps a double free at the second free AND an overrun at the guard page, in
the culprit's own stack. Neither fired. So on this configuration - four pods,
loopback, one teardown - the bug does not happen.
It also settles the address-space question: 2 works, **4 works**, 6 dies. The
fatal night's six-pod population is NOT reachable under full page heap on one
machine, so that population and this instrument cannot be had at the same
time here.
What is still different from the fatal night, in the order worth attacking:
repetition (one sample of an intermittent bug is nearly nothing - loop the
4-pod full-PH run many times), then the real network (three machines, so the
podium and its teardown land at genuinely different moments per pod, instead
of loopback's near-simultaneous ~0 ms).
### What the two clean runs change
Light page heap traps a **double free** at the second free. It does NOT trap