The Defense Drift<\/span><\/h4>\nNext was a crash in processEventEnableChampionAction<\/code>, but the more dangerous part of this bug wasn’t the crash. _actionDefense<\/code> is a lookup table indexed by action type, via _actionIndex<\/code>, but the code was indexing it with curChampion->_actionDefense<\/code> instead, the champion’s current defense value. That’s an arbitrary runtime number, not a valid index, so when it grew large enough to exceed the table size, the read went out of bounds and crashed outright. That part was at least loud and easy to notice.<\/p>\nThe real problem<\/strong> showed up when the stat stayed within bounds. The lookup would quietly succeed, but against the wrong table entry, subtracting an incorrect defense bonus every time a combat action ended. There was no crash, no error, nothing to flag it. Just a small wrong number applied again and again, every fight, every action. Over enough time, that drift compounded into a champion whose defense stat had wandered far from what it should be, sometimes ending up nearly immortal, sometimes alarmingly fragile, with nothing in the logs to explain why.<\/p>\nFix:<\/strong> a one-character typo fix, replacing _actionDefense[curChampion->_actionDefense]<\/code> with _actionDefense[curChampion->_actionIndex]<\/code>.<\/p>\nThe Gimme Slot Bug<\/span><\/h4>\nNext one came from the gimme debug command. Cmd_gimme<\/code> loops over every slot for a given thing type, but unused slots have their first word set to thingNone<\/code> and the loop wasn’t checking for that before passing them to getIconIndex,<\/code> which calls into getWeaponInfo<\/code> or getObjectType<\/code>. Those ended up reading garbage from empty slots, sometimes crashing.<\/p>\nFix:<\/strong> read the raw first word of each slot, and skip it with continue if it equals thingNone<\/code>.<\/p>\nThe Duplicate Item Bug<\/span><\/h4>\nAnother gimme bug. When it allocated a new item slot by copying thing data and bumping _thingCounts<\/code>, it forgot to update dummyThing’s index to point at the new slot, still handing over the original thingIndex<\/code> instead of thingCount<\/code>. Two references ended up pointing at the same thing slot, causing duplicate item corruption and crashes whenever one reference was modified or deleted.<\/p>\nFix:<\/strong> one line, dummyThing.setIndex(thingCount)<\/code>, after the allocation.<\/p>\nThe Object Aspect Crash<\/span><\/h4>\nNext one was inside drawObjectsCreaturesProjectilesExplosions<\/code>, the function responsible for rendering objects, creatures, and projectiles in the dungeon view. It chained getObjectInfoIndex<\/code> straight into _objectInfos[...]._objectAspectIndex<\/code> and then into _objectAspects209[...]<\/code>, all in one expression, with no validation along the way. But getObjectInfoIndex<\/code> can return an out-of-range value for invalid or corrupt things, and _objectAspectIndex<\/code> itself can exceed k85_ObjAspectCount<\/code>, causing crashes.<\/p>\nFix:<\/strong> guard both indices before use, skipping the object with continue if either is out of range.<\/p>\nAn Enum That Wasn’t One<\/span><\/h4>\nNext one was about ActiveGroup::_directions<\/code>, typed as Direction, an enum. But the field doesn’t actually store a single direction, it stores packed 2-bit direction values for up to 4 creatures combined together, built via getGroupValueUpdatedWithCreatureValue<\/code>. That’s a bit-packed integer, not a valid enum value, and casting a packed integer to an enum type is undefined behavior in C++.<\/p>\nFix:<\/strong> change the field type from Direction to uint16, and remove the (Direction) casts at every assignment site, letting the packed value be stored and manipulated as a plain integer like it should’ve been.<\/p>\nThe Freeze That Wouldn’t Crash<\/span><\/h4>\nThis one<\/strong> ate up most of my week, and it didn’t go down easy. The game would freeze, not crash, whenever explosives were thrown at certain creature groups. No ASan output to point at anything, since nothing was actually invalid memory. GDB’s backtrace wasn’t any more helpful either, it didn’t even surface the method actually responsible.
\nSo it came down to reasoning it out manually. The freeze only ever happened when throwing explosives at a group with loot to drop, which meant something to do with damaging groups and handing out their possessions. That pointed toward GroupMan<\/code>, so I started going through its methods one by one, comparing them against the original reversed code to spot where our implementation had drifted.
\nThat led to dropCreatureFixedPossessions<\/code>, which iterates a fixedPossessions<\/code> pointer array to hand out loot. Two early-exit continue paths, one for skipping a random drop, one for when no unused thing slot was available, both forgot to advance the pointer before looping back. Without that advance, the loop kept re-reading the exact same array entry forever, spinning in place instead of crashing.<\/p>\nFix:<\/strong> advance currFixedPossession = *fixedPossessions++<\/code> in both continue branches before skipping, so the loop always makes forward progress.<\/p>\nThe Projectile Crash<\/span><\/h4>\nNext one started simple, throw a sword or any projectile, and the game crashed. No obvious cause at first. Going through the methods from the GDB backtrace one by one eventually led to initializeGraphicData<\/code>, where the loop over 6 projectile scale levels was writing all 6 byte-counts to the same fixed offsets, derivedBitmapIndex<\/code>, derivedBitmapIndex+6<\/code>, derivedBitmapIndex+12<\/code>, every iteration, missing + projectileScaleIndex<\/code>. Only the last iteration’s values stuck, leaving every earlier entry sized incorrectly.<\/p>\nFix:<\/strong> add + projectileScaleIndex<\/code> to all three cache offsets, so each scale level writes to its own correct slot.<\/p>\nNew Addition<\/span><\/h4>\nAdded a nuke<\/code> debugger command. Killing monsters manually just to clear a path for testing wasted time, so nuke<\/code> finds the group directly in front of the party via mapCoordsAfterRelMovement<\/code> and groupGetThing<\/code>, then removes it instantly with groupDelete<\/code>. No gameplay impact.<\/p>\n\n
\n
\n
\n
\n
\n
\n
\n
Looking Ahead, Faster<\/strong><\/span><\/h3>\n<\/div>\nI’m going to push to finish the DM engine faster going forward, since there are more engines waiting in line after this one. I’ll do my best to wrap it up as quickly as I can, though I’ll admit, it’s turned out to be far more complex and broken than I initially expected.<\/p>\n<\/div>\n
Thank you for reading. See You in the Next One \ud83d\ude42<\/p>\n
\n <\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Hi, this is week 3 of my GSoC journey. After spending the last two weeks chasing crashes across the DM engine, this week turned into something more like detective work \u2014 digging into array indices, stale pointers, and byte alignment bugs that were quietly corrupting things under the hood. This week, I faced freezes along […]<\/p>\n","protected":false},"author":30,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-108","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/posts\/108","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/users\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/comments?post=108"}],"version-history":[{"count":47,"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/posts\/108\/revisions"}],"predecessor-version":[{"id":153,"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/posts\/108\/revisions\/153"}],"wp:attachment":[{"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/media?parent=108"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/categories?post=108"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.scummvm.org\/mohit\/wp-json\/wp\/v2\/tags?post=108"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}