Polyobj_OR_MoveToSpot Crash/Lockup

[Guest]

Start the map, press the door, and watch Zdoom lock up to the point that you have to reboot. No Crashlog is made it just locks up.

http://www.speedyshare.com/files/301888 ... _CRASH.wad

[Enjay]

It also locked up for me when I tried it in GZDoom but I was able to get back to the desktop and this had been printed to the console.

Code: Select all

**** DIED WITH FATAL ERROR:
Could not malloc 60 bytes

[edit] and Zdoom gives me the same message. [/edit]

[Tapwave]

Code: Select all

Could not malloc 60 bytes

Wow, what kind of polyobject would need so much memory it would run out of RAM with recent computers?

[Edward-san]

Code: Select all

Could not malloc 60 bytes

Wow, what kind of polyobject would need so much memory it would run out of RAM with recent computers?

No, that was fast memory leak, I'd say

It locked my pc definitely, so much I had to shut down my pc

[Enjay]

I wonder if it is related to the rotating polyobject lockup with the ZPack map?

http://forum.zdoom.org/viewtopic.php?f= ... 6&p=580330

[randi]

Anybody still have the file?

[Edward-san]

Here.

[Enjay]

FWiW, r3399 still locks up for me with this map and I still get the "Could not malloc 60 bytes" error when I manage to force my way back to the desktop.

[TheDarkArchon]

Interestingly, when I checked how much RAM GZDoom was using at the point it went boom, it was "only" using 1.89GB of RAM (I.E it hadn't completely swallowed the 2GB limit allowed by 32-bit programs in Windows).

EDIT: ZDoom r3394 went up to 1.91GB of RAM before moaning about it's inability to chomp through more RAM.

[Enjay]

I just checked on my system and it reported much the same memory use. I ran Zdoom on one screen and the task manager was visible on the other. When I tried to use the polyobject, the memory use went up in approximately 400MB jumps (slightly quicker than about 1 jump per second) 'til it got to around 1.9GB then it fluctuated up and down a bit around that value until I pressed PrtScrn. At that point I was dropped back to the desktop with the ZDoom console window showing the malloc error.

[Tapwave]

I'm probably going to sound stupid by saying this, but anyone tried to test this after applying the 4GB RAM patch on ZD/GZD?

[Xtyfe]

Interestingly, when I checked how much RAM GZDoom was using at the point it went boom, it was "only" using 1.89GB of RAM (I.E it hadn't completely swallowed the 2GB limit allowed by 32-bit programs in Windows).

EDIT: ZDoom r3394 went up to 1.91GB of RAM before moaning about it's inability to chomp through more RAM.

I just checked on my system and it reported much the same memory use. I ran Zdoom on one screen and the task manager was visible on the other. When I tried to use the polyobject, the memory use went up in approximately 400MB jumps (slightly quicker than about 1 jump per second) 'til it got to around 1.9GB then it fluctuated up and down a bit around that value until I pressed PrtScrn. At that point I was dropped back to the desktop with the ZDoom console window showing the malloc error.

That is one hell of a memory leak

[Gez]

I'm probably going to sound stupid by saying this, but anyone tried to test this after applying the 4GB RAM patch on ZD/GZD?

If a memory leaks gobbles up two gigs of RAM instantly, it'll gobble up 4 gigs of RAM instantly as well.

A slow memory leak, like maybe a megabyte every hour or so, well then, no problem. You can suggest workarounds that don't fix the issue but only alleviate the symptoms. A lightning fast memory leak, however, won't be assuaged just by giving it double the amount of memory. Maybe if you gave it a billion yottabytes, but that's not possible.

[Graf Zahl]

I haven't run it in the debugger yet but it's plainly obvious that the code gets stuck in an endless loop that repeatedly allocates some memory. It would exceed any amount that could be set.

[Blzut3]

The "leak" (not really a leak since the object will eventually get cleaned up) appears to be line 666 of po_man.cpp:

Code: Select all

	while ( (mirror = poly->GetMirror()) )
	{
		poly = PO_GetPolyobj(mirror);
		if (poly == NULL || (poly->specialdata != NULL && !overRide))
		{ // mirroring poly does not exist or is already in motion
			break;
		}
		// reverse the direction
		dist.X = -dist.X;
		dist.Y = -dist.Y;
		pe = new DMovePolyTo(mirror);
		poly->specialdata = pe;
		pe->m_Dist = xs_RoundToInt(distlen);
		pe->m_Speed = speed;
		pe->m_xSpeed = xs_RoundToInt(speed * dist.X);
		pe->m_ySpeed = xs_RoundToInt(speed * dist.Y);
		pe->m_xTarget = xs_RoundToInt(poly->StartSpot.x + distlen * dist.X);
		pe->m_yTarget = xs_RoundToInt(poly->StartSpot.y + distlen * dist.Y);
		polyNum = mirror;
		SN_StartSequence(poly, poly->seqType, SEQ_DOOR, 0);
		if (nointerp)
		{
			pe->StopInterpolation();
		}
	}

I'm not an expert on this piece of code, but having a loop there seems wrong to me. Doesn't FPolyObj::GetMirror() only return one possible value (Linedefs[0]->args[1])? If this is the case then I think every override function will lock up if the poly object has a mirror.

Edit: Actually on a second look I see where poly changes (first line of the loop of course). So the problem is each poly being the mirror of the other so the loop just flips between the two indefinitely.

I'm probably going to sound stupid by saying this, but anyone tried to test this after applying the 4GB RAM patch on ZD/GZD?

It's a case of an infinite loop. So on my 64-bit system it promptly ate all 8GB and started into the swap space as well. On a side note, valgrind isn't working with ZDoom for some reason.