Scirra
Memory crashes on large projects
Problem description
Hello! I am coming today to report an issue I've seen described many times in the past but never properly reproduced due to how hard it is to actually reproduce.
Large Construct 3 projects have been suffering for years from random memory crashes, most likely caused by the Construct 3 tab allocating too much memory on the heap while building spritesheets. I've heard this has happened on Astral Ascent, Biogun and Moonstone Island.
In the case of Astral Ascent and Moonstone Island, since the average sprite size is rather small (60 by 60px in the case of Moonstone Island) due to their pixel art style, they have been able to circumvent the issue by using browsers that have higher memory caps, like Microsoft Edge on Windows.
On Biogun, this higher cap seems to still have not been enough, since its average sprite size is much larger.
For the past 3 days I have decided to reproduce projects with an exact copy of the sprite sizes while jumbling the actual image data and removing anything in the project that isnt a texture. With that I was able to reproduce the memory crashes on Chrome and on Safari.
I am testing on a Macbook Pro M4 Pro with 48GB of RAM, so more than enough memory to run all of these tasks.
Attach a .c3p
Sorry for the rather large filesize, but as you may already know there is no way to reproduce a memory crash without overloading the memory. To make you feel better, be sure that these projects have nothing more than the exact image sizes used in the very real projects Biogun and Moonstone Island.
As such I can't attach the files here, but you will find them here: https://github.com/skymen/construct-memory-crashes
Steps to reproduce
- Render spritesheets
On my machine, this happens more often when using the biogun project.
Observed result
The tab crashes randomly
Expected result
The tab should not crash randomly
More details
Affected browsers/platforms: I know that most browsers are more or less affected depending on how they manage memory and what their memory cap per tab is. It happens most often on Chrome.
First affected release:
System details
View details
PASTE HERE
Oh hey!! I have also experienced tab crashes, sometimes full browser crashes with SkyRanch.Life. It was rare and couldn't really figure out what was happening.
I wonder if it's this issue. Running Win 10 with 32 gb ram.
Ok due to github straight up refusing to upload the biogun files, I'm gonna go through Google Drive: https://drive.google.com/drive/folders/1-P-Z8wmqUXr_YfmXs-17ocVap_FQ_vqi?usp=sharing
In our case, the Moonstone Island project often crashes with an out-of-memory error when saving, or sometimes just randomly while working in the editor - but not during spritesheet generation. That made me think the issue might not be tied only to graphics or image sizes, but more to the overall amount of resources in the project - events, layouts, files, etc.
We use tilemaps heavily, and today I found that removing just one tilemap object (we have about 500 instances of it across layouts) drops the editor's memory use by almost 1GB. I added this same tilemap to a blank project and created about 1000 instances of it. The project already eats close to 3GB of RAM. If you duplicate layout 31 a couple of times, move things around, hit preview or save - the out-of-memory crash is easy to reproduce.
https://www.dropbox.com/scl/fi/w5shzbuu2mmly80azvves/TilemapMemoryTest_dungeons2.c3p?rlkey=twms7f7qyx5eaxfbjm6he7nyi&st=h5iwb0jj&dl=0
In BioGun there aren't any tilemaps, but they've got 300 hand-built layouts (levels) with thousands of sprites each. So having a huge number of instances seems to contribute to the problem as well. Here's another test project: just a single sprite with about 400K instances. Again, it's right on the edge of the memory limit and will crash if you duplicate layouts or try other heavy operations.
https://www.dropbox.com/scl/fi/588x6ttpapdiaoc07hu4w/SpritesMemoryTest1.c3p?rlkey=lpp3kb8m9o0ydkx2vgg1i630q&st=828qdr9v&dl=0
Both of these test projects are under 10MB, which shows the game doesn’t have to be several gigs for this to happen - even relatively small projects can be crashing.
Construct already throttles the number of spritesheets that are rendered simultaneously, specifically to limit the peak memory usage and try to avoid out-of-memory issues. Currently the limit is the same as the 'Logical CPU cores' field in Platform Information, with the intent being to fully utilize all CPU cores and therefore render spritesheets as fast as the system allows. It would be useful if those affected could report their 'Logical CPU cores' count, as if you are on a system with an unusually large core count (e.g. 64 or 128) this may still allow a high peak memory usage. (The original report omits this information; please always follow the bug report guidelines to ensure we have the information we need.)
We could try reducing the limit, but that will impact performance, allowing some cores to remain idle when rendering spritesheets and causing it to take longer.
Separately, if you have a project that already occupies say 99% of available memory, and then you do a memory-intensive process like rendering spritesheets, it is not surprising that it would crash with an out of memory error, as you really have run out of the available memory. With modern 64-bit systems with lots of memory in theory there should be plenty of space, but I think some browsers limit certain kinds of JavaScript-addressable memory to 4 GB. @skymen - you mentioned Edge allows more memory, and I wasn't aware of that - do you have a reference for that? Perhaps a workaround for the time being is just to use Edge if that really does allow higher memory limits. We could also look at trying to optimize the memory use of the Construct editor itself, but that will likely consume a lot of development time and may not produce enough savings to meaningfully improve the situation for large projects.
Here are my system info:
Platform information Product: Construct 3 r449.2 (stable) Browser: Chrome 139.0.7258.155 Browser engine: Chromium Context: browser Operating system: macOS 15.6.0 Device type: desktop Device pixel ratio: 1 Logical CPU cores: 14 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36 Language setting: en-USLocal storage Storage quota (approx): 556 GB Storage usage (approx): 2 GB (0.4%) Persistant storage: Yes
Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported.
Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: no Vendor: Google Inc. (Apple) Renderer: ANGLE (Apple, ANGLE Metal Renderer: Apple M4 Pro, Unspecified Version) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 511 Extensions:
EXT_clip_control EXT_color_buffer_float EXT_color_buffer_half_float EXT_conservative_depth EXT_depth_clamp EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_polygon_offset_clamp EXT_render_snorm EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_mirror_clamp_to_edge EXT_texture_norm16 KHR_parallel_shader_compile NV_shader_noperspective_interpolation OES_draw_buffers_indexed OES_sample_variables OES_shader_multisample_interpolation OES_texture_float_linear WEBGL_blend_func_extended WEBGL_clip_cull_distance WEBGL_compressed_texture_astc WEBGL_compressed_texture_etc WEBGL_compressed_texture_etc1 WEBGL_compressed_texture_pvrtc WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context WEBGL_multi_draw WEBGL_polygon_mode WEBGL_provoking_vertex WEBGL_render_shared_exponent WEBGL_stencil_texturing Audio information System sample rate: 44100 Hz Output channels: 2 Output interpretation: speakers Supported decode formats:
WebM Opus (audio/webm;codecs=opus) WebM Vorbis (audio/webm;codecs=vorbis) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav;codecs=1) Supported encode formats:
WebM Opus (audio/webm;codecs=opus) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) Video information Supported decode formats:
WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034) Supported encode formats:
WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) WebM H.264 (video/webm;codecs=avc1.420034) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 VP9 (video/mp4;codecs=vp9) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034)
you mentioned Edge allows more memory, and I wasn't aware of that - do you have a reference for that?
Not really. It's mostly due to some trial and error and anecdotal evidence. I have read online and experimented myself that Chrome seems to be the most unstable with memory management, and I've been told that Edge seems to be more stable.
I've also read online that Edge (although this is from before Edge used Chromium) had better memory management than Chrome and ran smoother. There is also this bug report from a while ago that talks about Firefox's limit being different: https://issues.chromium.org/issues/40691287
Also, since I'm testing on MacOS I've also experimented with Safari and although it does seem to also have a similar limit, it did seem to be a bit more resilient in other memory heavy tasks such as copy pasting 200MB of layout data with all the image data inside of them. (Chrome would randomly hit a memory issue and would start to throw "fail to fetch" errors.
I'm wondering if a simple solution would be to allow triggering spritesheet generation manually, or save the result in the project files so they dont have to be regenerated accross sessions.
As for the case that dop reported, I have no idea how memory is managed inside of the editor, but would it be possible to only load the layout's data only after opening it for the first time, and also a way to force unload memory used by layouts that aren't currently in view?
Maybe it really is just a case of Chrome being so painfully limiting with memory usage that it would be akin to jumping through many hoops. In that case, is it fair to talk about reviving a desktop version of Construct using NW.js or Electron that doesnt suffer from those limitations?
I can confirm that Edge is a lot more stable for us. It still crashes, but only rarely - maybe once or twice a week. While Chrome was crashing multiple times a day. The error is the same: “Out of memory” John, the author of BioGun, mentioned that their project crashes in all browsers, both on PC and Mac.
My platform info: CPU AMD Ryzen 5 7600, 6 Core(s), 12 Logical Processor(s) RAM 64 GB
View details
Platform information Product: Construct 3 r449.2 (stable) Browser: Chrome 140.0.7339.81 Browser engine: Chromium Context: browser Operating system: Windows 10 Device type: desktop Device pixel ratio: 1.5 Logical CPU cores: 12 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Language setting: en-US
Local storage Storage quota (approx): 531 GB Storage usage (approx): 1.4 GB (0.3%) Persistant storage: Yes
Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported.
Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: no Vendor: Google Inc. (AMD) Renderer: ANGLE (AMD, AMD Radeon RX 6800 (0x000073BF) Direct3D11 vs_5_0 ps_5_0, D3D11) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions:
EXT_clip_control EXT_color_buffer_float EXT_color_buffer_half_float EXT_conservative_depth EXT_depth_clamp EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_polygon_offset_clamp EXT_render_snorm EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_mirror_clamp_to_edge EXT_texture_norm16 KHR_parallel_shader_compile NV_shader_noperspective_interpolation OES_draw_buffers_indexed OES_sample_variables OES_shader_multisample_interpolation OES_texture_float_linear OVR_multiview2 WEBGL_blend_func_extended WEBGL_clip_cull_distance WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context WEBGL_multi_draw WEBGL_polygon_mode WEBGL_provoking_vertex WEBGL_stencil_texturing Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats:
WebM Opus (audio/webm;codecs=opus) WebM Vorbis (audio/webm;codecs=vorbis) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav;codecs=1) Supported encode formats:
WebM Opus (audio/webm;codecs=opus) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) Video information Supported decode formats:
WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034) Supported encode formats:
WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) WebM H.264 (video/webm;codecs=avc1.420034) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 VP9 (video/mp4;codecs=vp9) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034)
It would be useful if those affected could report their 'Logical CPU cores' count, as if you are on a system with an unusually large core count (e.g. 64 or 128) this may still allow a high peak memory usage. (The original report omits this information; please always follow the bug report guidelines to ensure we have the information we need.)
Ashley needs this information in order to make any progress on this bug. Let's all contribute it.
Below are my system information details. I only have 8 logical cores and do not have any crashing issues, in any browser, when working on DaggerQuest, which has 146,455 images.
View details
Platform information Product: Construct 3 r449.2 (stable) Browser: Chrome 140.0.7339.82 Browser engine: Chromium Context: browser Operating system: Windows 11 Device type: desktop Device pixel ratio: 1 Logical CPU cores: 8 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 Language setting: en-US
Local storage Storage quota (approx): 268 GB Storage usage (approx): 3 GB (1.1%) Persistant storage: No
Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported.
Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: no Vendor: Google Inc. (NVIDIA) Renderer: ANGLE (NVIDIA, NVIDIA GeForce RTX 3060 (0x00002503) Direct3D11 vs_5_0 ps_5_0, D3D11) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions:
EXT_clip_control EXT_color_buffer_float EXT_color_buffer_half_float EXT_conservative_depth EXT_depth_clamp EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_polygon_offset_clamp EXT_render_snorm EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_mirror_clamp_to_edge EXT_texture_norm16 KHR_parallel_shader_compile NV_shader_noperspective_interpolation OES_draw_buffers_indexed OES_sample_variables OES_shader_multisample_interpolation OES_texture_float_linear OVR_multiview2 WEBGL_blend_func_extended WEBGL_clip_cull_distance WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context WEBGL_multi_draw WEBGL_polygon_mode WEBGL_provoking_vertex WEBGL_stencil_texturing Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats:
WebM Opus (audio/webm;codecs=opus) WebM Vorbis (audio/webm;codecs=vorbis) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav;codecs=1) Supported encode formats:
WebM Opus (audio/webm;codecs=opus) MPEG-4 Opus (audio/mp4;codecs=opus) MPEG-4 AAC (audio/mp4;codecs=mp4a.40.2) Video information Supported decode formats:
WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034) Supported encode formats:
WebM AV1 (video/webm;codecs=av01.0.00M.08) WebM VP9 (video/webm;codecs=vp9) WebM VP8 (video/webm;codecs=vp8) WebM H.264 (video/webm;codecs=avc1.420034) MPEG-4 AV1 (video/mp4;codecs=av01.0.00M.08) MPEG-4 VP9 (video/mp4;codecs=vp9) MPEG-4 H.265 (video/mp4;codecs=hev1.1.2.L93.B0) MPEG-4 H.264 (video/mp4;codecs=avc1.420034)
I've also had this issue when switching between layouts & especially when I use the load / unload (layout / images) methods.
I can reproduce this very well on old iPhones that have 4GB of ram or less, since Apple afaik has a lower memory limit per tab for these. Here is the WebKit bug report: https://bugs.webkit.org/show_bug.cgi?id=261685 ...this also includes an Xcode project with a construct application that loads a ton of large high-res images when switching layouts.
@therealPaulPlay Yours is a different issue. This report is about the C3 editor running out of memory and crashing, not about runtime crashes.