Save game buffer overflow

From DoomWiki.org

Vanilla Doom defines a hard limit on the size of savefiles. On some large levels, due to the number of things, this can result in a crash when the player tries to save the game. The limit seems to be about 180KB; it was raised in v1.4.

Because the number of things in a level changes during play, it is not generally possible to identify this bug without testing. Certain editors, such as DeePsea, can estimate the size of a savefile for each difficulty class.

Cause and fixes[edit]

As part of an effort to keep the amount of memory required by the game at or under 4 MB, the save game system reuses a portion of the screens video buffer in order to construct the data to be written to disk for saved games. In order to reuse this area, a static limit has to be enforced on the size of a saved game. The limit could have been avoided by dynamically allocating the buffer, but there would then be the equal risk of a Z_Malloc error when saving on large maps.

More thorough fixes include either using direct file IO, a reallocating buffer (as implemented first in Boom by Lee Killough), or by streaming the data out to disk - using a static-sized buffer, the contents are purged to file each time the buffer is filled. These both require more sophisticated input and output code than was employed by the original game.

Hexen is not subject to the save game size limit, as its rewritten save game system uses direct file IO, writing each field of the internal structures directly. This is potentially slower, as it depends on the standard library's IO functions or the underlying operating system to have sufficient internal buffering.

Well-known maps[edit]

The following is a list of well known vanilla maps that can cause the game to crash upon saving:

Retrieved from "https://doomwiki.org/w/index.php?title=Save_game_buffer_overflow&oldid=496272"