Z_CT: Uh oh.

[forgettable pyromaniac]

Ok, so... long, LONG story short, I might've fucked something up, and I don't understand what-

Still workin' on MI over here, and the error I got-

"Z_CT at w_wad.c:510"
Z_CT is defined on the Doomwiki as:

Z_CT at %s:%i

A cache tag change operation has referenced a memory block which did not contain the value 0x1d4a11 in the header. This error can only occur in the event of heap corruption.

Andddd... I'm getting this error specifically when opening a specific map in a dehacked EXE with the intended PWAD.
Opening in Chocolate doesn't seem to produce this error, even with the exact same Dehacked patch.

I'm not asking what I can do to FIX, I'm asking what it MEANS, so I can at least see what I fucked up.

If I gotta upload, I'm ok with that, just don't wanna unless I gotta because my internet provider hates me really bad rn.
Thanks in advance :)

[forgettable pyromaniac]

On 9/2/2022 at 9:15 PM, forgettable pyromaniac said:

Update - was deleting some stuff in the dehacked patch to see if any of them would fix it - there was a string causing the error of all things. after editing it, they worked? strange, but okay.

IT WAS A FUCKING MIDI

A MIDI WAS CRASHING IT AAAAAAAAAAA

[forgettable pyromaniac]

Update - was deleting some stuff in the dehacked patch to see if any of them would fix it - there was a string causing the error of all things. after editing it, they worked? strange, but okay.

[Gez]

What's the problem with the MIDI ? Is it too large to be converted to MUS on-the-fly? Or is it malformed in some way? Just trying to figure out how it would induce heap corruption so those are my first guesses.

[forgettable pyromaniac]

On 9/4/2022 at 3:28 PM, Gez said:

What's the problem with the MIDI ? Is it too large to be converted to MUS on-the-fly? Or is it malformed in some way? Just trying to figure out how it would induce heap corruption so those are my first guesses.

SHIT sorry i didn't get back to you. The midi is only 2.88kb 2.25kb. ima make another wad archive now and see if it'll still cause the issue. will let you know.

https://files.catbox.moe/smgzg0.wad - idclev to map31 works in chocolate doom (3.0) but crashes with

Z_CT at w_wad.c:510

in the original executable.

i think it's just the midi's fault but it's kinda interesting.

Edited September 6, 2022 by forgettable pyromaniac : tested it, uploaded file / wrong kb number

[Gez]

Thanks. I don't see anything special about that MIDI lump. Size should be safe, it's the most basic type of MIDI file (format 0).

 

Now, in the released source code, w_wad.c line 510 doesn't contain anything special, it's just the second parameter of the function definition for W_CacheLumpName. However, we know that the released source code was "cleaned up" by Bernd Kreimeier, so to debug vanilla error reporting, the line numbers are misleading and sometimes the filenames are, too.

 

The Z_CT error message is caused by this macro:

//
// This is used to get the local FILE:LINE info from CPP
// prior to really call the function in question.
//
#define Z_ChangeTag(p,t) \
{ \
      if (( (memblock_t *)( (byte *)(p) - sizeof(memblock_t)))->id!=0x1d4a11) \
	  I_Error("Z_CT at "__FILE__":%i",__LINE__); \
	  Z_ChangeTag2(p,t); \
};

So in other words, it's an error that can only happen in calls to the function Z_ChangeTag. In w_wad.c, there's only one call to it, so provided Kreimeier didn't split some code from w_wad.c into something else, we can suppose it's this one:

//
// W_CacheLumpNum
//
void*
W_CacheLumpNum
( int		lump,
  int		tag )
{
    byte*	ptr;

    if ((unsigned)lump >= numlumps)
	I_Error ("W_CacheLumpNum: %i >= numlumps",lump);
		
    if (!lumpcache[lump])
    {
	// read the lump in
	
	//printf ("cache miss on lump %i\n",lump);
	ptr = Z_Malloc (W_LumpLength (lump), tag, &lumpcache[lump]);
	W_ReadLump (lump, lumpcache[lump]);
    }
    else
    {
	//printf ("cache hit on lump %i\n",lump);
	Z_ChangeTag (lumpcache[lump],tag);
    }
	
    return lumpcache[lump];
}

So it found the lump successfully (first if is skipped) and it was in cache (second if is skipped, going into else).

 

I admit I'm completely at a loss why this causes heap corruption here.

[maxmanium]

It's probably something to do with the code that converts midi lumps to mus. Since we don't have DMX source code who knows why. I've only ever seen this happen with midis that are too big, but maybe it's just caught up on it for some other reason.

[forgettable pyromaniac]

11 hours ago, Gez said:

Thanks. I don't see anything special about that MIDI lump. Size should be safe, it's the most basic type of MIDI file (format 0).

 

it found the lump successfully (first if is skipped) and it was in cache (second if is skipped, going into else)...

 

... I admit I'm completely at a loss why this causes heap corruption here.

it's really strange tbh. I wouldn't even know where to start so just knowing that is kinda cool. 

 

11 hours ago, maxmanium said:

It's probably something to do with the code that converts midi lumps to mus. Since we don't have DMX source code who knows why. I've only ever seen this happen with midis that are too big, but maybe it's just caught up on it for some other reason.

I remember reading somewhere at one point the code got leaked, but dont quote me on that... 

[Gez]

Maybe @fraggle, @kgsws, @NY00123 or @nukeykt could find out the explanation. It's definitely above my skill.

[Dark Pulse]

I know in the past I remember some videos about how certain MIDI files could just make the engine shit the bed.

 

 

[nukeykt]

DMX adds end of track event at the memory chunk end for single track midi formats and thus overwrites some of doom's heap data. You can either convert midi file to multitrack MIDI (format 1) or just add 3 extra bytes at the end of file in any hex editor.

[Gez]

Mystery solved! Thanks Nukey.