Weird ass thing

[revelator]

So im fiddling with my TQX engine and rebuild it well guess what debug builds Work fine but any hint of optimization crashes it wtf
Anyone got a hint on what the hell can cause such a thing ?

[r00k]

I seem to have the same problem, debug doesnt crash, though the release randomly crashes on map change. I think i have a null pointer somewhere in gl_rmisc.c.
I cant get the debug to crash, and when i latch on to the app it really doesnt offer much about the crash.

I'm in the process of taking a stable build and painstakingly adding the changes one feature at a time, then testing each build for a couple days (online gameplay too) until i find the point it crashes.

[Spike]

it should generally be possible to include debug information even with various optimisations.
or you can try running it via valgrind. that'll generally detect uninitialised stack variables and stuff.

[r00k]

is there a valgrind binary for windows 32?

[revelator]

there is but its buggy :/ better to use drmemory.
My tqx engine has a built in memory debugger but so far i have not been able to get anything relating to a null pointer from its output.

[revelator]

ah speak of the devil the built in memory ddebugger finally fired

WARNING: Access out of range; SUFFIX of block sized 11 bytes, allocated at
4F220FA8 (no label) by function Z_Malloc (line 111 of
D:\Tq148X\zone.c) at Wed Mar 20 00:18:40 2013 using `malloc', has
been corrupted.

im using mh's cleaned up memory manager :S

explodes here

void *Z_Malloc (int size)
{
int *zblock = (int *) malloc(size + sizeof(int)); // kaboom yes this is highly irritating

if (!zblock)
{
Sys_Error ("Z_Malloc: failed on allocation of %i bytes", size);
}
memset (zblock, 0, size + sizeof (int));

zblock[0] = ZONEID;

return (zblock + 1);
}

It only happens once at start but its enough to crash it Cold on win7 with the latest patches. Im starting to Wonder if ms has gone ape on memory bugs ?? since lately some of my normally working games have stopped working, im also getting a bsod from time to time that points to a ram error but i checked the ram using memtest and several other tools and they all tell me my ram are ok. So maybe a bug in ms patches hmm.

[Spike]

if in windows+msvc, link against the debug msvc runtime rather than the release one, and sprinkle calls to _CrtCheckMemory throughout your code (even with optimisations enabled).
This will check all your malloc blocks for obvious memory corruption without sideeffects.
It won't help with stack errrors though.

microsoft have enabled dep (which breaks winquake) and they have changed their runtimes (so freeing stack memory is properly detected, but this needs you to relink against a more recent runtime).
microsoft just want your buggy programs to stop working.

[frag.machine]

This

Code: Select all

int *zblock = (int *) malloc(size + sizeof(int));

Shouldn't be this instead ?

Code: Select all

int *zblock = (int *) malloc(size * sizeof(int));

[Spike]

... are they not the same?

[revelator]

heh funny that you noticed that i was also wondering about that one its indeed a + not a * it uses add not multiply symbol ???? hmm im going to try and change that and see what happens.

[revelator]

Ok it seems to be intended to use + instead i tried this and it seems to have fixed the corruption

int *zblock = (int *) malloc(sizeof(int) + ((size + 31) & ~31)); // hmm fixed the memory corruption by rounding it off to 32 bytes

[Spike]

Your memory block is (mis?)aligned to an int. aligning the size of the alloc to 32 bytes is completely pointless because its still only got int alignment.
If that 'fixes' it then the issue is an overflow, and you should fix the caller and not hack the callee. Just randomly adding 32 to the result would have the same (possibly more robust) effect... Its a stupid thing to do though, just fix the caller instead!

sse would prefer 16-byte alignment instead of 4-byte alignment, but you need to align the start rather than the total size for it to be useful to sse.
Either way your code would probably be better if the int was an intptr_t instead, to keep things aligned in 64bit builds.

Side note:
Replacing Z_Malloc with an actual malloc like your code does may result in issues in 64bit builds as the location of certain zoned strings are no longer at a specific offset relative to the progs string table, or may cause issues with mods that use qccx hacks (but then pretty much everything might causes issues with that sort of mod, so meh).

[revelator]

hmm the codes not mine its mh's :s i was wondering about the int cast also i would have thought to use a byte ptr instead.

[frag.machine]

... are they not the same?

Code: Select all

int *zblock = (int *) malloc(size + sizeof(int));

Code: Select all

int *zblock = (int *) malloc(size * sizeof(int));

let's say size = 100 and sizeof (int) = 4, then you're saying:

Code: Select all

100 + 4 == 100 * 4

I'm not trying to be ironic BTW, I actually fail to see how this can be the same.

[frag.machine]

Ok it seems to be intended to use + instead i tried this and it seems to have fixed the corruption

int *zblock = (int *) malloc(sizeof(int) + ((size + 31) & ~31)); // hmm fixed the memory corruption by rounding it off to 32 bytes

Quite complex, huh ? Also, seems it will kaboom again in 64 bit architecture, right ?