OAL memory allocation insanity? (ENTIRE COMPUTER FREEZES)

[phantombeta]

I've stumbled upon a serious problem with GZDoom.
Something can cause GZDoom to start allocating RAM until it has allocated all the RAM available and the computer is completely frozen. I believe this is a problem with either the sound code, or OpenAL itself.
The only thing I can think of is that it's doing something when it runs out of channels, and it also only seems to happen when the channel limit is set to 256. (I might be wrong about this)

I simply don't know anything else about this. Although I am on a 64-bit system, my computer only has 2 GB of RAM, so GZDoom simply freezes the computer when this happens. (and I can't buy more RAM)
Due to this, I can't really test it to even get a crash report.

Basically, the easiest way to make it happen is to execute this in the console:

Code: Select all

playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;playsound *pain;

However, it doesn't always cause it to consume all RAM: sometimes GZDoom crashes with an access violation, but whether GZDoom crashes or simply freezes the entire computer seems random.

I've had to force-restart several times trying to figure out what could be causing this, so I'm not risking frying my computer to try to get a crash report, specially considering it seems to cause GZDoom to fail to execute the exception handling code properly.
If I had some way to limit the maximum amount of RAM GZDoom can use, I'd try to get a crash report, but I can't seem to find a way to do so.

System specs in case it might be useful: (From Speccy)

Code: Select all

Operating System
	Windows 10 Pro 64-bit
CPU
	Intel Celeron G530 @ 2.40GHz
	Sandy Bridge 32nm Technology
RAM
	2.00GB Single-Channel DDR3 @ 532MHz (7-7-7-20)
Motherboard
	Positivo Informatica SA POS-EIH61CE (SOCKET 0)
Graphics
	LG TV (1920x1080@60Hz)
	SMILE56X (1366x768@60Hz)
	Intel HD Graphics (Elitegroup)
Storage
	149GB SAMSUNG HD161HJ (SATA)
Optical Drives
	HL-DT-ST DVDRAM GH24NS95
Audio
	Áudio do vídeo Intel

[Graf Zahl]

Do you have virtual memory enabled?
If not, there's nothing that can be done. If Windows runs out of memory it will become unstable, if you are lucky you'll be able to terminate the app that has eaten it all, but no such guarantees.

You have to accept that your system has limited resources so you will not be able to max out certain settings that consume a lot of memory.

[phantombeta]

I do have virtual memory enabled.
However, uh, GZDoom shouldn't suddenly start using 1000 MB of RAM for no reason at all.

[Graf Zahl]

I'll have to wait for a response by Chris about this. If OpenAL internally allocates too much memory the problem needs to be fixed at the source.

[_mental_]

I cannot reproduce this issue: pain sound is playing as it should with 256 sound channels. Memory usage was about 130 MB.
Could it be related to Áudio do vídeo Intel whatever it is? Because I'm using cheap USB headset and this test case works fine for me.

What's the version of GZDoom by the way? Could you please try to reproduce the problem without config file?
Probably it's a good idea to disable virtual memory temporary. So Windows will kill the process in case of out-of-RAM instead of infinite HDD thrashing.

[ibm5155]

Áudio do vídeo Intel is just a driver that sends audio data through the HDMI cable (it looks like he's using that).
But before bigger tests, try to start gzdoom with the "-nosound" arg and see if the same happens.
It would be nice to also test the builds with fmod, because if it happens in both you may have some software that's Adding crap under gzdoom. (And since you live in Brazil, there are some bank softwares that increase the ram usage of every "app", like, there was a time where a simple C hello world with a specific bank software installed had the ram usage increased from 600KB to 37MB!!!)

[phantombeta]

@_mental_ & Graf
I'm on g3.2pre-333-gb1d1ac1.
"Áudio do vídeo Intel" is indeed the HDMI audio device as ibm5155 said. (it's portuguese for "Intel video's audio", in a literal/direct translation)
So, I disabled virtual memory. Instead of freezing, Windows showed me a window telling me to close GZDoom. Anyway, got some crash reports now. The first one was from putting a lot of "playsound *pain;"s in a single line (about 256) and executing that. That crashed it.
The other happened by doing that a single time again, but it only crashed after I tried to type in the console, IIRC.
One thing I should mention is that for some reason the log file in the crash reports is missing this line:

Code: Select all

>>>>>>>>>>>> Received AL error Invalid Operation (0xA004), oalsound.cpp:1519

This line only appeared after closing the ZDoom Very Fatal Error window. After that, it just output that line and froze instead of closing.

There were also times when it didn't crash and just started outputting this to the console whenever a sound was meant to play:

Code: Select all

>>>>>>>>>>>> Received AL error Out of Memory (0xA005), oalsound.cpp:1619

I'm pretty sure there's some memory leak either in OpenAL or in GZDoom's code for the OpenAL backend, because this doesn't happen in FMOD. (Tested in g2.3pre-4-g475077f. It did happen with the OpenAL backend in that too.)
I guess just playing normally would make it happen too... In fact, I've had GZDoom spam ">>>>>>>>>>>> Received AL error Out of Memory (0xA005), oalsound.cpp:1619" to the console while playing before.
It's just that spamming "playsound *pain;" in the console makes it leak memory faster.

@ibm5155
Yeah, I did test without sound. Using literally ANYTHING other than OpenAL didn't leak memory like that.
And no, I don't have anything like that installed. This is a clean install of Windows 10, no OEM crap. I also don't use bank software, so it wouldn't be that. (And I'm 16 anyway, so no bank accounts to use a bank program for, and I'm the only person who uses this computer)

[Graf Zahl]

What's the size of your OpenAL32.dll in bytes? Since this is a devbuild I'd like to make sure it's a recent version.

[phantombeta]

@Graf
Filesize is 845045 bytes. MD5 hash is 02124c71572adb101fe7fce4a850073d.

[ibm5155]

hm mine is 980543 bytes on devbuild.
Related to this MD5: Steam link
EDIT: Try to change your output sound device in gzdoom

[Graf Zahl]

845045 is the 32 bit version from the official OpenAL download as of Jan 2016. The one in official 3.1.0 is 866816 bytes. Please download that version and replace your DLL. It may well be that the leak is something that is fixed in the latest self-compiled version.

[phantombeta]

@Graf
That fixed it. I tested it with Mor'Ladim's Bullet Eye.
Using the give all cheat and firing the Volley Shot makes it spawn a lot of explosions with sounds. (Morladim-BulletEyev0.9.3b.pk3, specifically)
The old DLL GZDoom start spamming ">>>>>>>>>>>> Received AL error Out of Memory (0xA005), oalsound.cpp:1619". The newer DLL works fine, with no error messages and no memory leaks. (At least apparently)

However, the sound is now really weird. None of the resamplers sound like the old DLL. Is there any way to fix that?

[Chris]

However, the sound is now really weird. None of the resamplers sound like the old DLL. Is there any way to fix that?

Both DLLs default to Linear resampling. Make sure to Restart Sound after changing the resampler for it to take effect (the option just changes the cvar, and the cvar is read when sound is initialized).

[phantombeta]

@Chris
It seems it's something with HRTF. Turning it off makes the sound normal again.

[_mental_]

There is no embedded HRTF data in older DLL. So this feature cannot work until you have two special files accessible for GZDoom.
I'm almost sure that you didn't have them, so like the initial memory issue HRTF is also [Not ZDoom].
Presence of obsolete OpenAL32.dll in devbuild packages is totally different story.