-zone to prevent crashing

[mh]

calloc clears the allocated memory to 0, malloc doesn't. The default behaviour of Z_Malloc is to clear to 0, and there are places in the code that assume it's been cleared to 0 (some I've found, some I no doubt haven't) so it's safer.

[necros]

just to clarify on above assumptions:

this is quakespasm 0.85.4, x64 (not 'stock' fq085)

this is with my own mod (not quoth)
a single pak file (or no pack file and just loose files)

it is not happening at consistent times, however, that could mean nothing as the mod itself is highly random.

maybe the default zone size is larger for quakespasm, because when i run with -zone 256, the engine crashes immediately on loading a map with:
Z_Realloc: failed on allocation of 49960 bytes
(Z_Reallloc, no Z_Alloc btw, not a typo)

[qbism]

Wow, zone can be gone now. At this point is there any reason to keep zone on any platform? Maybe older machines/ OS's (DOSquake?) or ancient compilers?

[Baker]

Quakespasm 0.85.4 seems to have something different going on here ..

Code: Select all

#define   PR_STRING_ALLOCSLOTS   256

static void PR_AllocStringSlots (void)
{
   pr_maxknownstrings += PR_STRING_ALLOCSLOTS;
   Con_DPrintf("PR_AllocStringSlots: realloc'ing for %d slots\n", pr_maxknownstrings);
   pr_knownstrings = (const char **) Z_Realloc ((void *)pr_knownstrings, pr_maxknownstrings * sizeof(char *));
}

Quakespasm 0.85.4 is using a default of 384 KB instead of 256 KB.

[mh]

Yeah, I spotted that and it seems a bit of an abuse of what is a fairly limited memory space to me. Allocating zone space for temp strings/etc (and basically any string from progs.dat ends up in the zone with the QS code) might not have been the best idea.

[Spike]

when it comes to frik_file, you have to ensure that those strings are properly flushed at the end of each map.

map loading can just use heap - the qc will never try to free them anyway, although this may give 16+ bytes of overhead per allocation, it should at least be 64-bit safe.

zone memory is at least useful for ensuring that qc-accessible strings are in a known memory range, permitting the use of 32bit pointers in a 64bit address space. Its also useful for tagging regions for bulk freeing, should that be useful (it is with q2, where the gamecode's allocs are freed in one fel swoop, although this can be done as a tiny layer above malloc). Other than that, yeah, ditch the zone, its not thread safe anyway.

If you do want to keep it, there's no reason that you can't create multiple zone blocks, mallocing a new one when you run out, although that won't help with the 64bit-strings issue.

For debugging, valgrind is much much much more useful than sentinals and hacking your own mem allocators.

[necros]

seems to be a totally quakespasm thing then.

i ran fq085 with -zone 256 (i know it's supposed to be default but just in case) and it was able to load everything fine.

since everyone's got huge gobs of ram anyway though, i'll just continue to suggest using -zone 2048 until you guys remove zone completely, or whatever.

thanks for clearing this up a bit more for me.