From 74948fdd1030320d90c5baa0dabea68a99d6eeee Mon Sep 17 00:00:00 2001 From: Cyd Date: Fri, 14 Aug 2026 10:13:29 -0500 Subject: [PATCH] The podium survives a full page heap, four pods deep 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) --- tools/podium-repro/README.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/tools/podium-repro/README.md b/tools/podium-repro/README.md index 6b81e73..ba2af1a 100644 --- a/tools/podium-repro/README.md +++ b/tools/podium-repro/README.md @@ -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