Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce Mem_MallocA() that is like alloca() but falls back to heap memory for bigger allocations #627

Merged
merged 5 commits into from
Nov 7, 2024

Conversation

DanielGibson
Copy link
Member

@DanielGibson DanielGibson commented Oct 31, 2024

The use of plain alloca() causes stack overflows (or assertions meant to prevent them) when models with many polys are loaded, see #528

Mem_MallocA() is a macro that that uses _alloca16() for allocations < 1MB, and otherwise uses Mem_Alloc16(). It should be used together with Mem_FreeA() to free the memory if it came from Mem_Alloc16(). A bool variable must be passed to Mem_MallocA() and Mem_FreeA(), it will be set to true if _alloca16() was used and false otherwise, and Mem_FreeA() uses it to do the right thing.

This is kinda like Microsoft's _malloca() and _freea(), except that doesn't need the additional bool because they can do platform-specific magic to detect whether memory is on the stack.

This could use a little more testing with unusually big models.
I tested it by playing a few levels of Prometheus and Doom 2553, according to #528 (comment) they caused problems before.

When requesting < 1 MB, _alloca16() is used, otherwise Mem_Alloc16().
Furthermore you must pass a bool that will get true assigned if the
memory has been allocated on the stack, else false.
At the end of the function you must call Mem_FreeA( ptr, onStack )
(where onStack is the aforementioned bool), so Mem_Free16() can be
called if it was allocated on the heap.
one step to making HD models (like
https://www.moddb.com/mods/birdman-doom3/downloads/birdman-doom3-v11 )
work, but there's still other places in the code where the HD version
of that model makes dhewm3 crash
I hope that should cover all relevant cases, though there are still
plenty of _alloca() and _alloca16() calls left throughout the code
loosely based on dhewm#517, with additional fallback to base.dll if the one
for fs_game_base isn't found either
also changed that logic a bit so FormatMessage() is only called when
actually used

and while at it, fixed the build with mingw-w64 on my system
(somehow an SDL header used strcmp() and that didn't work with
 `#define strcmp idStr::Cmp` from Str.h)
@DanielGibson DanielGibson merged commit 218813e into dhewm:master Nov 7, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant