Help regarding the VM Execution BEEFCAFE pointer

[Guest]

Hello,

I am a new user of the forum, so forgive any newbie mistakes. I did not know where to post the issue either, since it seems somewhat weird...

Me and my friend have recently been enjoying HeXen coop using Thetis's Wrath of Cronos mod. We enjoyed it so much, that I've learned enough ZScript to edit the mod to the point of creating new mobs and adding a new additional class. To put it shortly, somewhere in the middle of the next "hub", the Seven Portals, the skills of my new class cease working, usually replaced with the default string of "Passive" or "Not learned yet". And it' is weird, because they have worked for hours, with the mob generating Director on, flawlessly, then suddenly break, resulting in a VM Execution error pointing to 00000000BEEFCAFE whenever any of us attempt to change levels, even the console command.

I was wondering if anyone had any clue regarding where to look at, because I have double-tripple checked the new class, all the monsters, and nothing to my knowledge out of place... If anyone is actually interested, I would happily provide the .PK3, crashlog or save file(though it's meant for 2 players).
I do know that the issue is revolving around the new class and potentially something that "breaks" the skill cycle, but don't know what...

[_mental_]

Please post everything you have.

[Gez]

I don't know the mod and I haven't dabbled in ZScript, so I can't provide any precise insight. But 0xBEEFCAFE looks like a debug value, so it seems you're accessing data that was freed. If that happens when changing level, it must mean that the data it tries to access is level data that was cleaned out.

[capnbunnypaws]

Hello,

I am a new user of the forum, so forgive any newbie mistakes. I did not know where to post the issue either, since it seems somewhat weird...

Me and my friend have recently been enjoying HeXen coop using Thetis's Wrath of Cronos mod. We enjoyed it so much, that I've learned enough ZScript to edit the mod to the point of creating new mobs and adding a new additional class. To put it shortly, somewhere in the middle of the next "hub", the Seven Portals, the skills of my new class cease working, usually replaced with the default string of "Passive" or "Not learned yet". And it' is weird, because they have worked for hours, with the mob generating Director on, flawlessly, then suddenly break, resulting in a VM Execution error pointing to 00000000BEEFCAFE whenever any of us attempt to change levels, even the console command.

I was wondering if anyone had any clue regarding where to look at, because I have double-tripple checked the new class, all the monsters, and nothing to my knowledge out of place... If anyone is actually interested, I would happily provide the .PK3, crashlog or save file(though it's meant for 2 players).
I do know that the issue is revolving around the new class and potentially something that "breaks" the skill cycle, but don't know what...

Edit: We are using LZDoom version 3.88a, the latest official.

(Posting again because I forgot to log in last time. I apologize)

[capnbunnypaws]

Please post everything you have.

Save file https://drive.google.com/file/d/1Y2CbK9 ... sp=sharing

Mod https://drive.google.com/file/d/1zBgKTO ... sp=sharing

Crash report https://drive.google.com/file/d/1Lg1LG0 ... sp=sharing

I hope this helps.

[_mental_]

---

Code: Select all

0x7ff77949780e   AActor::UnlinkFromWorld
0x7ff77949e274   AActor::OnDestroy
0x7ff7793f52b5   DObject::Destroy
0x7ff779536dc9   DCorpsePointer::OnDestroy
0x7ff7793f52b5   DObject::Destroy
0x7ff7793fbcb8   DThinker::DoDestroyThinkersInList
0x7ff7793fbb2b   DThinker::DestroyAllThinkers
0x7ff7794bea75   P_FreeLevelData
0x7ff7794c2d8e   P_SetupLevel
0x7ff77940c79e   G_DoLoadLevel
0x7ff77940ccbc   G_DoWorldDone
0x7ff779408cb0   G_Ticker
0x7ff7793ed9c0   TryRunTics
0x7ff7793e56e8   D_DoomLoop

Presence of DCorpsePointer makes me think that it's the same corpse queue crash, just for the old codebase. Most likely, a WriteBarrier is missing somewhere.

[capnbunnypaws]

---

Code: Select all

0x7ff77949780e   AActor::UnlinkFromWorld
0x7ff77949e274   AActor::OnDestroy
0x7ff7793f52b5   DObject::Destroy
0x7ff779536dc9   DCorpsePointer::OnDestroy
0x7ff7793f52b5   DObject::Destroy
0x7ff7793fbcb8   DThinker::DoDestroyThinkersInList
0x7ff7793fbb2b   DThinker::DestroyAllThinkers
0x7ff7794bea75   P_FreeLevelData
0x7ff7794c2d8e   P_SetupLevel
0x7ff77940c79e   G_DoLoadLevel
0x7ff77940ccbc   G_DoWorldDone
0x7ff779408cb0   G_Ticker
0x7ff7793ed9c0   TryRunTics
0x7ff7793e56e8   D_DoomLoop

Presence of DCorpsePointer makes me think that it's the same corpse queue crash, just for the old codebase. Most likely, a WriteBarrier is missing somewhere.

Sorry for the silly question, but where do I find the exact line on LZDoom 3.88a? I understood the fix in question, but fail to find the location while browsing the lzdoom.pk3. Unless I am looking in the wrong location?

[drfrag]

I don't think it's the same crash, with your sample script it didn't crash and the implementation of the corpse queue is the old one.
But how do i reproduce the crash? Have you loaded the savegame? I cannot load it with the command line "-file woc_4.pk3 -loadgame ZdoomedBros1.zds" it says that it cannot find it.

[Graf Zahl]

That would be in the C++ source, not in script code.
As a first test, I'd suggest you remove the A_QueueCorpse call from NewDisciplePlayer and BaseDisciplePlayer. This function is meant for monster corpses and may cause some issues with dead players.

[_mental_]

I don't think it's the same crash, with your sample script it didn't crash and the implementation of the corpse queue is the old one.

Did you do all the steps needed to trigger overflow of corpse queue during GC propagation? Even if so, this doesn't mean that the old implementation is bug-free.
It's based on garbage collected objects and a linked list (own stat thinkers), so the error could be pretty much anywhere.

But how do i reproduce the crash? Have you loaded the savegame?

I reconstructed the callstack from the provided crash dump. Debugging it with coop saved game is out of scope for me.

[capnbunnypaws]

I don't think it's the same crash, with your sample script it didn't crash and the implementation of the corpse queue is the old one.
But how do i reproduce the crash? Have you loaded the savegame? I cannot load it with the command line "-file woc_4.pk3 -loadgame ZdoomedBros1.zds" it says that it cannot find it.

I am not certain about the loadgame, but we have. The loadgame worked, we could move, do actions, kill all monsters/baddies with the console, but the moment we entered a portal, or used the changemap command, it instantly crashed with the aforementioned error. I have no idea why the loadgame does not work, I did add it all as it were in the folder. Perhaps it being a two player multiplayer has something to do with it?

We will currently be testing Graf Zahl's solution, which was removing the A_QueueCorpse from the player definitions. I will deliberately kill my player at the beginning of the hub and we will see if we can complete it without issues.

[drfrag]

It's loaded from the command line but not from the debugger, seems the file is in use by VS itself but i get the error "savegame is from a different level".
From Vs the internal my_wstat64 function returns -1 since GetFileAttributesExW fails.

[drfrag]

Okay wrong working directory, about the different level is that becouse they were using hexen 1.0 instead of 1.1? I guess that's the case.

id you do all the steps needed to trigger overflow of corpse queue during GC propagation?

I did and i already had checked that bug in the past.

[_mental_]

The bug isn't the same as the mentioned one in the modern codebase. However, it's still about double freeing of an object.
I suspect, the problem is in addition of a pointer to more than one thinker lists, STAT_PLAYER and STAT_CORPSEPOINTER.
This explains why changing a level is needed in order to reproduce the crash.

[capnbunnypaws]

That would be in the C++ source, not in script code.
As a first test, I'd suggest you remove the A_QueueCorpse call from NewDisciplePlayer and BaseDisciplePlayer. This function is meant for monster corpses and may cause some issues with dead players.

We have tried your solution, and it seems to have worked. The player I was using did not leave a corpse as before, and did not trigger an error thoughout our playthrough. So that seems to be solved, the error was that I copypasted the Disciple monster's code, without considering it as a player, leaving it to queue up a corpse as a monster.
However, there is still the issue of the skills suddenly ceasing functioning. I cannot provide anything to reproduce the error, but I could try describing the conditions, since this isn't a case of a crash, rather than something changing states bizzarely. The issue occurred consistently at the end of the Seven Portals, after pressing the three levers needed to open the exit. The skills I had on my player character were mainly CallCleric, CallFighter, CallMage. For the vast part of the game, they worked as intended: if nothing exists, summon; if it exists, ThingMove; if double clicked, remove. However, after passing said stage, the skills would either show a "Passive" text or a "Not Learned" text, without any idea why.
It isn't the original issue, but maybe you could enlighten us regarding a potential cause? We would be very grateful.