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

Fix glass panel dead-button crash: null-init MessageHandlerSet gap slots (Gitea #18)

Browse Source 
Clicking a per-display glass Engineering panel button (0x21 on an Eng page)
hard-crashed via a wild call through an uninitialised pointer (eip=cdcdcdcd
debug / 0x01048748 release), zero btl4 frames above Receiver::Receive.

Root cause is the dense message-handler-table gap hazard (reconstruction-
gotchas #11), the message-side twin of the attribute-table one -- NOT a /FORCE
unresolved external (the glass link log carried only the known-benign mech3.obj
CreateStreamedSubsystem set). Receiver::MessageHandlerSet::Find(id) returns
messageHandlers[id-1].entryHandler for any id <= entryCount with no populated-
check, and Receive() calls it when != NullHandler. The streamed Eng-page .CTL
dispatches subsystem msg id 3/0xb to whatever subsystem is shown; a weapon
(Emitter) registers only PoweredSubsystem 4-8 + MechWeapon 9-10, so id 3 is a
gap below entryCount 10. Build did new HandlerEntry[entryCount] and left gaps
uninitialised -> (this->*garbage)(msg). The 1995 binary has the identical non-
zeroing new[] (part_002.c Build) and survived only on fresh-heap-zero luck: a
weapon receiving id 3 was always meant to IGNORE it (id 3 = a Condenser/
Reservoir action in a different subsystem branch; the uniform Eng-page button
template makes buttons for unimplemented actions authentically inert). The new
per-display windows just made the id reachable live.

Fix (engine, class-wide, faithful): Build now null-inits every slot
(entryID=0/entryName=""/entryHandler=NullHandler) before copying inherited /
placing supplied, so a gap is deterministically NullHandler -> Receive drops it
(the authentic "Receiver ignores unhandled messages"), with an empty never-NULL
name so the name-based Find() strcmp can't deref a gap. Correct dispatch
contract, not a glass-path guard -> protects the whole dead-button class (#14).

Also lands the [glasswin] CLICK crash-forensics log (names the button before
dispatch).

Verified under cdb: click-soaked every MFD bank (Engineering/L+R Weapons/Heat/
Comm, ~130 clicks through Quad<->Eng page cycles) -> zero AVs, reconstructed
mapper preset selects still fire ([mode] preset (1,1)/(2,1)...); pod build +
solo mission un-regressed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-20 15:59:37 -05:00
co-authored by Claude Fable 5
parent bc5ac3a0db
commit 5ba5697a08
4 changed files with 93 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
engine/MUNGA/RECEIVER.cpp
+30
View File
@@ -454,6 +454,36 @@ Check_Table:
messageHandlers = new Receiver::HandlerEntry[entryCount];
Check_Pointer(messageHandlers);
Register_Pointer(messageHandlers);
//
//-----------------------------------------------------------------------
// FAITHFUL FIX (Gitea #18 / reconstruction-gotchas #11 -- the glass
// dead-button crash). Find(id) returns messageHandlers[id-1].entryHandler
// for ANY id <= entryCount with no populated-check (RECEIVER.h Find), and
// Receive() calls it whenever it is != NullHandler. A message id that NO
// class in the receiver's chain registers but that is < entryCount lands on
// a GAP slot -- e.g. the streamed Eng-page .CTL dispatches subsystem msg id
// 3 / 0xb to a shown weapon (Emitter) whose handler chain only registers
// PoweredSubsystem 4-8 + MechWeapon 9-10, so slot[2] (id 3) is a gap below
// entryCount 10. operator new[] leaves these POD slots UNINITIALISED, so
// the gap held heap garbage and Receive did (this->*garbage)(msg) -> AV
// (debug CRT fill 0xCDCDCDCD; a recycled release block 0x01048748). The
// 1995 binary has the IDENTICAL non-zeroing new[] (part_002.c Build) and
// only survived on fresh-OS-heap-zero luck (a zero slot == NullHandler ==
// ignored). Make that intended "Receiver ignores unhandled messages"
// DETERMINISTIC: null every slot up front so a gap is NullHandler (Receive
// drops it) with an empty -- never NULL -- name so the name-based Find()
// strcmp cannot dereference a gap. Inherited/supplied handlers overwrite
// their slots below; only the true gaps stay null.
//-----------------------------------------------------------------------
//
for (i=0; i<entryCount; ++i)
{
messageHandlers[i].entryID = 0;
messageHandlers[i].entryName = "";
messageHandlers[i].entryHandler = Receiver::NullHandler;
}
i = 0;
if (inheritance)
{