0000453: More memory error stuff

[Matt]

https://mantis.zdoom.org/view.php?id=453

Seems to be a continuation of issue 410.

Sometimes it's something like

gzdoom: malloc.c _int_free: Assertion `nextchunk->fd_nextsize->bk_nextsize == nextchunk' failed.

Other times (when I'm not specifically trying to reproduce this) it's something like

*** Error in `/home/mchan223/doom/./gzdoom': corrupted double-linked list: 0x0000000003b23d70 ***

(user: Matthew the Glutton)

[_mental_]

So how to reproduce this?

[Matt]

Pretty much the same as issue 410:

1. Load HD: https://github.com/MatthewTheGlutton/Hi ... 340a55b140

2. "iddqd; summon HDMImp;"

3. Let it beat you up for a minute or so

4. Exit

5. See some random memory-related error in the console (or sometimes ***Fatal Error*** and a freeze requiring you to forcequit GZDoom to exit the program entirely)

[Matt]

It seems that I cannot reproduce this if I were to insert this "return" here:

Code: Select all

	override void A_MChaseThink(int flankdistance=128,int nofear=false){
		super.A_MChaseThink(256,nofear);
return;
		if(fatigue>8)decision&=~HDMCT_AIMSHOOT;
		if(fatigue>4)decision&=~HDMCT_COVERFIRE;
		if(fatigue>0)fatigue--;
	}

The constants are thus:

Code: Select all

const HDMCT_HOLD = 0;
const HDMCT_RETREAT = 2;
const HDMCT_ADVANCE = 4;
const HDMCT_COVERFIRE = 8;
const HDMCT_AIMSHOOT = 16;

I've also got this &= stuff in the healer imp, but it's only called occasionally rather than every time the imp goes into the see state. If this is what's causing the problem then that would explain why I can replicate this so readily with the mage but not the other imps.

(edit: updated the code now that I realize what I've been doing wrong this whole time. The issue with the memory glitching persists, however.)

[_mental_]

I managed to reproduce the issue with minimal set of changes. Just need some time to figure out how to fix it.

[_mental_]

Partially fixed by this commit.
Release build (compiled by GCC with -O3 switch) is still affected by some unrelated problem.

[Matt]

Since your fix I have not been able to reproduce this, so I think it can be closed as fixed?

[_mental_]

No, the memory issue on exit in Release builds produced by GCC is still there. Unfortunately I have no idea how to fix it at the moment.

[Graf Zahl]

Do you have any information you can post? Maybe it shows me something.

[_mental_]

Here is address sanitizer report:

Code: Select all

==16083==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210005a6518 at pc 0x00000146a1ba bp 0x7ffde9bd7dd0 sp 0x7ffde9bd7dc0
READ of size 4 at 0x6210005a6518 thread T0
    #0 0x146a1b9 in VMFrameStack::Alloc(int) (/home/user/gzdoom/build/gzdoom+0x146a1b9)
    #1 0x146a307 in VMFrameStack::AllocFrame(VMScriptFunction*) (/home/user/gzdoom/build/gzdoom+0x146a307)
    #2 0x146af4c in VMFrameStack::Call(VMFunction*, VMValue*, int, VMReturn*, int, VMException**) (/home/user/gzdoom/build/gzdoom+0x146af4c)
    #3 0xb01858 in DObject::Destroy() (/home/user/gzdoom/build/gzdoom+0xb01858)
    #4 0xdcd9b4 in AActor::DestroyAllInventory() (/home/user/gzdoom/build/gzdoom+0xdcd9b4)
    #5 0xe044a0 in AActor::OnDestroy() (/home/user/gzdoom/build/gzdoom+0xe044a0)
    #6 0xb01864 in DObject::Destroy() (/home/user/gzdoom/build/gzdoom+0xb01864)
    #7 0xb3c2d4 in DThinker::DestroyThinkersInList(FThinkerList&) (/home/user/gzdoom/build/gzdoom+0xb3c2d4)
    #8 0xb3c40f in DThinker::DestroyAllThinkers() (/home/user/gzdoom/build/gzdoom+0xb3c40f)
    #9 0xe55d18 in P_FreeLevelData() (/home/user/gzdoom/build/gzdoom+0xe55d18)
    #10 0xe57155  (/home/user/gzdoom/build/gzdoom+0xe57155)
    #11 0x56bd69 in call_terms() (/home/user/gzdoom/build/gzdoom+0x56bd69)
    #12 0x7fde8fde5ff7  (/lib/x86_64-linux-gnu/libc.so.6+0x39ff7)
    #13 0x7fde8fde6044 in exit (/lib/x86_64-linux-gnu/libc.so.6+0x3a044)
    #14 0x564183 in I_GetEvent() (/home/user/gzdoom/build/gzdoom+0x564183)
    #15 0xabd354 in NetUpdate() (/home/user/gzdoom/build/gzdoom+0xabd354)
    #16 0x68fd50 in swrenderer::NoAccelPlayerSprite::Render(swrenderer::RenderThread*) (/home/user/gzdoom/build/gzdoom+0x68fd50)
    #17 0x696bba in swrenderer::RenderPlayerSprites::RenderSprite(DPSprite*, AActor*, float, float, double, double, double, int, FDynamicColormap*, bool) (/home/user/gzdoom/build/gzdoom+0x696bba)
    #18 0x69c137 in swrenderer::RenderPlayerSprites::Render() (/home/user/gzdoom/build/gzdoom+0x69c137)
    #19 0x702573 in swrenderer::RenderScene::RenderActorView(AActor*, bool) (/home/user/gzdoom/build/gzdoom+0x702573)
    #20 0x702f03 in swrenderer::RenderScene::RenderView(player_t*) (/home/user/gzdoom/build/gzdoom+0x702f03)
    #21 0x704879 in FSoftwareRenderer::RenderView(player_t*) (/home/user/gzdoom/build/gzdoom+0x704879)
    #22 0xaaba00 in D_Display() (/home/user/gzdoom/build/gzdoom+0xaaba00)
    #23 0xaad9ce in D_DoomLoop() (/home/user/gzdoom/build/gzdoom+0xaad9ce)
    #24 0xab24db in D_DoomMain() (/home/user/gzdoom/build/gzdoom+0xab24db)
    #25 0x5358b4 in main (/home/user/gzdoom/build/gzdoom+0x5358b4)
    #26 0x7fde8fdcc82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #27 0x55ea08 in _start (/home/user/gzdoom/build/gzdoom+0x55ea08)

0x6210005a6518 is located 24 bytes inside of 4096-byte region [0x6210005a6500,0x6210005a7500)
freed by thread T0 here:
    #0 0x7fde91acbcaa in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99caa)
    #1 0x146ad7a in VMFrameStack::~VMFrameStack() (/home/user/gzdoom/build/gzdoom+0x146ad7a)

previously allocated by thread T0 here:
    #0 0x7fde91acb6b2 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x996b2)
    #1 0x146a0e7 in VMFrameStack::Alloc(int) (/home/user/gzdoom/build/gzdoom+0x146a0e7)

I was running Release build at 6760e01 compiled by GCC 5.4 using the following command line:

Code: Select all

./gzdoom -iwad doom2 -file HideousDestructor +map map10 +god +summon HDMImp

[_mental_]

I've attached the report because Mantis screwed it a bit.

Tried with deoptimized dobject.cpp and dobjgc.cpp but it didn't help.
However the same thing for vmframe.cpp solved the problem.
Moreover forcing -O0 flag for just file content still causes the issue.
It seems to be related to code from dobject.h and headers it includes.
https://mantis.zdoom.org/file_download. ... 5&type=bug

[_mental_]

Like I said before this is an optimization issue in GCC. Other compilers are not affected by this bug.
I put the issue on hold just in case somebody will want to invest time into it.