diff options
| author | Simon Howard | 2014-10-16 23:25:52 +0000 |
|---|---|---|
| committer | Simon Howard | 2014-10-16 23:25:52 +0000 |
| commit | d5b6bb70919f91f94b035b12ff706ef9ab08689c (patch) | |
| tree | ff0e53a6bbcf6d83791507fc97e4a5083c0bf6b3 /src/m_controls.h | |
| parent | c7e82b3866134277e73f9a9d2b0f67da3fa403d0 (diff) | |
| download | chocolate-doom-d5b6bb70919f91f94b035b12ff706ef9ab08689c.tar.gz chocolate-doom-d5b6bb70919f91f94b035b12ff706ef9ab08689c.tar.bz2 chocolate-doom-d5b6bb70919f91f94b035b12ff706ef9ab08689c.zip | |
Fix crash caused by adding a new WAD file.
This fixes #442, a crash caused by adding a new WAD file after a
lump has been loaded (and cached) from a previous WAD. This
manifested when playing using the Freedoom IWADs and also loading
a PWAD at the same time. The Freedoom IWADs have DEHACKED lumps
that are loaded from within the IWAD file.
The ultimate cause (thanks to Fabian Greffrath for uncovering it)
is that lumpinfo is realloc()ed after each new WAD load to store
the lumpinfo_t structures from the new WAD. If a lump has been read
and cached from a previous WAD file, it may end up having an invalid
'user' pointer that points to somewhere in the old lumpinfo[] array,
not the new one.
I think this bug was masked because realloc() will often not move
data if the previous location can simply be extended. The bug was
discovered when loading BTSX as a PWAD, probably because it's a
large WAD that contains a lot of lumps, and forced a move during
realloc.
Diffstat (limited to 'src/m_controls.h')
0 files changed, 0 insertions, 0 deletions