GameMaker Memory Allocation Crash on near-finished project (Memory allocation failed: Attempting to allocate 67108864 bytes)

Bagoman

Member
Hey there! This is my first post on the forums so excuse me if anything in here breaks protocol.

I've been working on a rather large project for about 2 and a half years now, and in the past few weeks as we've hit the end of adding assets, people have started reporting this crash:

___ ############################################################################################ FATAL ERROR in action number 1 of Draw Event for object obj_objective_parent: Memory allocation failed: Attempting to allocate 67108864 bytes at gml_Object_obj_objective_parent_Draw_0 ############################################################################################ -------------------------------------------------------------------------------------------- stack frame is gml_Object_obj_objective_parent_Draw_0 (line -1)

It's always on line -1, and has been called from pretty much every object I have. It can't be a memory leak since sometimes it'll even happen right on the launch of the game - and it doesn't reproduce, happening seemingly at random. It also happens sometimes before any surfaces other than the application surface are drawn, and most posts I've read on the subject point to excess surfaces as a potential culprit. I don't know if I need to just scale some of my assets down, since the game is massive and any assets that would be in are now in, but I really need to get this sorted out and am at a loss for solutions.

Starting to get pretty frustrated since it'll happen in create events, draw events, anything that gets run - it might produce this bug. The byte allocation amount is always 67108864. Hoping someone here has had experience with this and might point me in the right direction. Again, sorry if I'm breaking protocol in some way with this post, new to posting on the forums.
 
This is exactly 64 mb, which makes me think it's maybe some sort of cache problem. Like it's trying to put more than 64mb of cache on a device that has less than that.
Going to need to see some code and have more info to diagnose more , but this is my first feeling.
What platform(s) are you exporting to/having problem with?
 

Bagoman

Member
This is exactly 64 mb, which makes me think it's maybe some sort of cache problem. Like it's trying to put more than 64mb of cache on a device that has less than that.
Going to need to see some code and have more info to diagnose more , but this is my first feeling.
What platform(s) are you exporting to/having problem with?
It's exclusively on windows (both the game and the crash), and people are getting this crash even on some beastly setups (one with 32 gigs of ram and a 1080).
 
It's exclusively on windows (both the game and the crash), and people are getting this crash even on some beastly setups (one with 32 gigs of ram and a 1080).
This would be related to the HDD cache size (often overlooked when buying/building a PC). No amount of power or RAM or GPU could compensate for that.
Try to know if this happens on machines with a 64MB cache hard drive (or less)
 
Last edited:

Bagoman

Member
This would be related to the HDD cache size (often overlooked when buying/building a PC). No amount of power or RAM or GPU could compensate for that.
Try to know if this happens on machines with a 64MB cache hard drive (or less)
Here for 2 messages and already getting pointed in a much better direction than where I was looking, thanks so much for being willing to help with this!

I'm checking in with my testers to have them check their cache sizes. I guess the question would then be how to stop from flooding the cache - I take it this isn't an overall project size issue and more that I just have too much going on at once.

First Tester to check in - 64 MB cache. Adds up that I've never had the cache as mine is 256 MB
 

Joe Ellis

Member
I've had this same error, the guy I'm working with, I sent him my project and he got the same error message but with 1073741824 bytes, which is exactly 1024 gb. It seems such a weirdly accurate amount, and it doesn't happen on my pc.
That might have blown the cache size theory out the window :/
It seems like a weird bug though, I have the feeling it's a bug on yyg's end that might get fixed hopefully..
It also seems a strange coincidence that you've also been working on your project for over 2 years and only started getting this error the last few weeks.
 
Here for 2 messages and already getting pointed in a much better direction than where I was looking, thanks so much for being willing to help with this!

I'm checking in with my testers to have them check their cache sizes. I guess the question would then be how to stop from flooding the cache - I take it this isn't an overall project size issue and more that I just have too much going on at once.

First Tester to check in - 64 MB cache. Adds up that I've never had the cache as mine is 256 MB
Makes sense so far. Maybe too soon still to draw conclusions, but yeah...If I had a gun to my head and HAD to take a wild guess, it would be it.
What's your architecture like, generally? Do you let the user dynamically add his own resources in the game, like sprites, sounds and such?
Are your resources well organized in texture/audio groups, and loaded/unloaded as they are used?
Do you use 3rd party much larger sprites that you simply rescale in-game?
You know...this kind of stuff?

And yes, the cache is the "buffer" where things gets stored before reading/writing to the "main" memory.
If it didn't happened at at once, you'd be ok, as long as the HDD has enough time to make room for the next data coming in.

It also seems a strange coincidence that you've also been working on your project for over 2 years and only started getting this error the last few weeks.
So far, it seems hardware-specific, so it could have been like that for a long time, but has not been tested on various machines, hence remained undetected.

EDIT:
@Joe Ellis You say you had this error with 1024 MB?!? Yeah, that does not feel good for the cache theory, sorry I missed that part of your reply...
Did you ever got around it? Do you use a spinner, or a SSD? Do you know about your partner's?
 
Last edited:

Bagoman

Member
Makes sense so far. Maybe too soon still to draw conclusions, but yeah...If I had a gun to my head and HAD to take a wild guess, it would be it.
What's your architecture like, generally? Do you let the user dynamically add his own resources in the game, like sprites, sounds and such?
Are your resources well organized in texture/audio groups, and loaded/unloaded as they are used?
Do you use 3rd party much larger sprites that you simply rescale in-game?
You know...this kind of stuff?

And yes, the cache is the "buffer" where things gets stored before reading/writing to the "main" memory.
If it didn't happened at at once, you'd be ok, as long as the HDD has enough time to make room for the next data coming in.


So far, it seems hardware-specific, so it could have been like that for a long time, but has not been tested on various machines, hence remained undetected.

Users aren't able to add any dynamic resources, all is stored in the IDE/build. Texture groups are pretty well organized, audio groups less so but all compressed. The largest sized assets are 1920x1080, with a majority of assets significantly smaller than that.

I'm going to take a look into memory leaks and functionality where I read/write a lot and push a new build - should be able to tell better if the crash is still happening. Do you happen to know if its possible for things to get stuck and clog up the cache or am I just calling 64+ MB at a single time?
 
I'm going to take a look into memory leaks and functionality where I read/write a lot and push a new build - should be able to tell better if the crash is still happening. Do you happen to know if its possible for things to get stuck and clog up the cache or am I just calling 64+ MB at a single time?
Good question, mate. The answer is: it kinda depends.
The thing is, cache doesn't just pull out the exact data you need, it also pulls out some of the data around it, in chunks. Now, if that data is of use at that particular time or not all depends on how you are setup. Arrays, for examples, have continuous memory location, hence why looping through them is so fast). Other things may or may not be right to each other in memory. So if you try to pull a decent amount of data, from a decent amount of places all at the same time, if they are scattered all throughout memory, you may very well clog up, even if the data you are calling itself is less than 64 megabytes.
I hope that made sense.
 

Joe Ellis

Member
1024 GB !!
It's strange, my friend has used earlier versions of my project for a few months, but only came across this error the last few weeks since updating.
I am just hoping it's a bug in this version. I don't know what to do otherwise, there isn't any pattern or logic I can see as why it's happening.

That's a good bit of advice btw about memory allocation, a single array's memory is like a solid block all next to each other, whereas thousands of them can be scattered everywhere. It's a good reason to use "1D grids", a single array for a whole grid, you just have to do extra calculations to turn the 2 coordinates into a 1. Probably ends up worth it though.
 

Bagoman

Member
Good question, mate. The answer is: it kinda depends.
The thing is, cache doesn't just pull out the exact data you need, it also pulls out some of the data around it, in chunks. Now, if that data is of use at that particular time or not all depends on how you are setup. Arrays, for examples, have continuous memory location, hence why looping through them is so fast). Other things may or may not be right to each other in memory. So if you try to pull a decent amount of data, from a decent amount of places all at the same time, if they are scattered all throughout memory, you may very well clog up, even if the data you are calling itself is less than 64 megabytes.
I hope that made sense.
This makes perfect sense, thank you. Going to try to stagger some loading better, and I'm plugging up some memory leaks that I somehow managed to miss in my last pass - will push a new build and see if that fixes it. Helps a lot to know which testers are able to replicate the bug due to cache size, so you've already been such a huge help :)
 
No problem. Let me know if you need things checked out after your refactoring/debugging, I have a couple PCs with anything from lightning-fast SSD to toasters with old spinners HDD.
If it works on 64mb cache disks, and not on 32mb ones, I'd say screw those cheap rigs, and just bump up the minimum requirements for the hard drive a little bit, that's not really the end of the world.
 

Joe Ellis

Member
@Slow Fingers, Crap, while I was dividing the 1073741824 by 1024 on the calculator I added an extra step in my head. How embarrassing.
Well, still that's quite a step up from 64mb. So it might not be cache related. My pc definitely doesn't have a 1gb cache.
 
@Slow Fingers, Crap, while I was dividing the 1073741824 by 1024 on the calculator I added an extra step in my head. How embarrassing.
Well, still that's quite a step up from 64mb. So it might not be cache related. My pc definitely doesn't have a 1gb cache.
I never even heard of a hard drive with 256mb+ cache...
Maybe they exists at NASA or US Navy, but certainly not at BestBuy! 😂
 

Joe Ellis

Member
@Amon luckily their experts are ready to help:


In all seriousness though, yeah at this point SSD is a lot better performance wise, the bigger the disc, the further the reader\spinner has to move. And SSD's don't use a spinner do they? Just electrical signals or something like ram but a hard drive version.? I'm not very uptodate with hardware


He even has a transparent background, I love him!
 
Last edited:
Yeah, SSD looks like a flash stick with a PCIe connector, nothing moves, it's all quiet, and about 20x faster.
From pressing the power button to a fully loaded OS takes about 2 seconds on a SSD, it's quite amazing.
 

Joe Ellis

Member
Yeah that's definitely the future, you can even see that with how much faster usbs have gotten, whole audio interfaces are connected with them 32bit sound with about 2ms latency.
I've heard a lot about SSD's the last few years, hardrives will be phased out eventually. I'm probably gonna wait a few more years then the next pc I get will have a big ass SSD. Or hopefully a solid state hard drive (SSHD) *nods with a futuristic aura*
 
If you have a spare PCIe slot, it's worth just to get like a 256 gB just for the OS and apps you use all the time. It really makes that much of a difference
 

Joe Ellis

Member
Tbh the most intensive app I use is gm while it's compiling, maybe it'd be worth it for that cus my project takes about 30 seconds to compile now. I don't mind though, I kind of miss loading screens on games in a weird way. I also never play new games on my pc, I do on my ps4, but the only new game I've got on my pc is cuphead, and that surprisingly loads almost instantly, I think it streams all the data for each level though, so it's still loading it while you're on the world map part.
I do agree though that all the new hardware is worth getting, but I can't be bothered with installing individual parts at a time. I always just every 5 years or so get a pc that's $5\600. At that price range (and scouting around) you get one that's solid and lasts years. But I will def be getting one with a SSD, I need to see what it's all about after waiting this long.
 

chamaeleon

Member
64MB is also the memory required for a texture page of size 4096x4096, I think? Any chance you're doing something that eats up too much VRAM and not release it, causing the allocation of such a texture page to fail? Would be interesting to know what kind of actions take place in the draw events in general.
 

Juju

Member
Sorry to be a party pooper but this is nothing to do with hard drives and also probably not a texture allocation issue either. Errors of this kind are typically vertex buffer-related, specifically GM's internal vertex buffer it uses for batching.

Could you share the code you're running in that script please?
 
Sorry to be a party pooper but this is nothing to do with hard drives
Yeah, we figured that much with the same error, but with 1GB of allocation, which threw the cache theory out of the window.
It seems to crash when trying to fire up the draw event, as far as I can gather from Googling this error message and checking people's error messages, so vertex buffers is possible. "Memory allocation failed" is, to say the least, rather generic!
And I also did mention we'd need code to really know what's going on in my first post, but hey... nevermind me! 😂

Do you happen to have gotten that in some form and fixed it in the past?
 

Joe Ellis

Member
This is the error message my friend got:

############################################################################################
ERROR in
action number 1
of Create Event
for object <undefined>:

Memory allocation failed: Attempting to allocate 1073741824 bytes
############################################################################################

So I've got no way of narrowing it down. I'm going to ask him more about when it happens, cus I can't seem to recreate the error on my pc.
I thought it might be something getting stuck in an infinite loop, like creating a huge amount of instances until it can't handle any more..
I'm going to test some things like this out this week to try and recreate the same error message and I'll post back if I find anything.
 

Roldy

Member
This is the error message my friend got:

############################################################################################
ERROR in
action number 1
of Create Event
for object <undefined>:

Memory allocation failed: Attempting to allocate 1073741824 bytes
############################################################################################

So I've got no way of narrowing it down. I'm going to ask him more about when it happens, cus I can't seem to recreate the error on my pc.
I thought it might be something getting stuck in an infinite loop, like creating a huge amount of instances until it can't handle any more..
I'm going to test some things like this out this week to try and recreate the same error message and I'll post back if I find anything.
As my original reply states here and as @Juju indicates it is most likely a vert buffer issue. The thread I linked to hints at a way to verify this by changing the texture page size (it will change the allocation error amount). But the problem is most likely a vert buffer growing too large; consider custom text, vector graphics or particle effects as these can ramp up the vert count.
 

Joe Ellis

Member
I don't have any code that draws, builds vertex buffers or anything else like that in any object's create events, but I'm going to ask my friend to change the texture page size and see if the memory amount changes.
I think my error and the op's are from different causes, cus of the size difference and how his is in the draw event. I think that one is more likely to be related to vertex buffers or textures.. Mine could be too though. I really wish I had some way of narrowing it down..
 
Top