• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!
  • Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

GMS 2.3+ Garbage Collector is crashing with "null pointer dereference" on physics object!

Tornado

Member
After migrating our game from GMS 2.2 to 2.3 we are facing very strange crash.
It seems that Garbage Collector is crashing with null pointer exception!!!
We are using physics engine (box2d). It seems that garbage collector and physics engine doesn't do well together.

On Windows it crashes withouth any output, on Android is crashes with "null pointer dereference":
(Take a closer look on the lines with DoGenerationalGC, MarkAndSweepGen and b2Fixture::Destroy)
Code:
09-27 18:51:51.721 25167 25167 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-27 18:51:51.721 25167 25167 F DEBUG   : Build fingerprint: 'lge/judypn_lao_eea/judypn:10/QKQ1.191222.002/2021917599e76:user/release-keys'
09-27 18:51:51.721 25167 25167 F DEBUG   : Revision: '12'
09-27 18:51:51.721 25167 25167 F DEBUG   : ABI: 'arm64'
09-27 18:51:51.722 25167 25167 F DEBUG   : Timestamp: 2020-09-27 18:51:51+0200
09-27 18:51:51.722 25167 25167 F DEBUG   : pid: 24914, tid: 24949, name: GLThread 10524  >>> com.abcgames.abcpinball1 <<<
09-27 18:51:51.722 25167 25167 F DEBUG   : uid: 10374
09-27 18:51:51.722 25167 25167 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
09-27 18:51:51.722 25167 25167 F DEBUG   : Cause: null pointer dereference
09-27 18:51:51.722 25167 25167 F DEBUG   :     x0  0000000000000000  x1  0000007a26cc5aa0  x2  0000000000000000  x3  000000000000000a
09-27 18:51:51.722 25167 25167 F DEBUG   :     x4  0000007a9e78bc20  x5  0000007a9e78bc40  x6  0000007a391de798  x7  0000007a391de790
09-27 18:51:51.722 25167 25167 F DEBUG   :     x8  0000000000000000  x9  00000000000192a0  x10 0000007a264974f8  x11 000000005cf9f389
09-27 18:51:51.722 25167 25167 F DEBUG   :     x12 0000000000000018  x13 000000000000008b  x14 0000000000000000  x15 0000000000000089
09-27 18:51:51.722 25167 25167 F DEBUG   :     x16 0000007a3e5bd6a8  x17 0000007a3e3bb778  x18 0000000000000100  x19 0000007a26c33040
09-27 18:51:51.723 25167 25167 F DEBUG   :     x20 0000007a26cc5aa0  x21 0000007a26c33040  x22 0000007a26cded40  x23 0000007a26cdedd0
09-27 18:51:51.723 25167 25167 F DEBUG   :     x24 0000007a26cdede8  x25 0000000000000000  x26 0000000000008a17  x27 0000000000000001
09-27 18:51:51.723 25167 25167 F DEBUG   :     x28 0000000000000002  x29 0000007a3f90fc30
09-27 18:51:51.723 25167 25167 F DEBUG   :     sp  0000007a3f90fc10  lr  0000007a3e3bc350  pc  0000007a3e3bb794
09-27 18:51:51.884 25167 25167 F DEBUG   :
09-27 18:51:51.884 25167 25167 F DEBUG   : backtrace:
09-27 18:51:51.884 25167 25167 F DEBUG   :       #00 pc 00000000003f7794  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (b2Fixture::Destroy(b2BlockAllocator*)+28) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #01 pc 00000000003f834c  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (b2World::DestroyBody(b2Body*)+336) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #02 pc 000000000033cf00  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (CPhysicsObject::~CPhysicsObject()+112) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #03 pc 000000000025a3a0  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (CInstance::PreFree()+32) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #04 pc 0000000000173c24  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (MarkAndSweepGen(int, int, bool)+2592) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #05 pc 00000000001746c0  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (DoGenerationalGC(int)+208) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #06 pc 00000000002ab90c  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (DoAStep()+80) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #07 pc 00000000002ac19c  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (MainLoop_Process()+1024) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #08 pc 00000000003af854  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/lib/arm64/libyoyo.so (Java_com_yoyogames_runner_RunnerJNILib_Process+868) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #09 pc 00000000000224c0  /data/app/com.abcgames.abcpinball1-VvMEsTV0RG9fx4GT6igGXw==/oat/arm64/base.odex (art_jni_trampoline+208)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #10 pc 00000000020082d8  /memfd:/jit-cache (deleted) (com.abcgames.abcpinball1.DemoRenderer.onDrawFrame+696)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #11 pc 0000000000136334  /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #12 pc 0000000000144fec  /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #13 pc 00000000002e27fc  /apex/com.android.runtime/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+384) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #14 pc 00000000002dda5c  /apex/com.android.runtime/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+892) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #15 pc 00000000005a1464  /apex/com.android.runtime/lib64/libart.so (MterpInvokeInterface+980) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #16 pc 0000000000130a14  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_interface+20) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #17 pc 00000000002f53b0  /system/framework/framework.jar (android.opengl.GLSurfaceView$GLThread.guardedRun+1096)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #18 pc 00000000005a2278  /apex/com.android.runtime/lib64/libart.so (MterpInvokeDirect+1100) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #19 pc 0000000000130914  /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_direct+20) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #20 pc 00000000002f598c  /system/framework/framework.jar (android.opengl.GLSurfaceView$GLThread.run+48)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #21 pc 00000000002b3b10  /apex/com.android.runtime/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEbb.llvm.15427027571776522123+240) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #22 pc 0000000000591214  /apex/com.android.runtime/lib64/libart.so (artQuickToInterpreterBridge+1032) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #23 pc 000000000013f468  /apex/com.android.runtime/lib64/libart.so (art_quick_to_interpreter_bridge+88) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #24 pc 0000000000136334  /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #25 pc 0000000000144fec  /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #26 pc 00000000004afc18  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #27 pc 00000000004b0d2c  /apex/com.android.runtime/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue const*)+416) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #28 pc 00000000004f16e8  /apex/com.android.runtime/lib64/libart.so (art::Thread::CreateCallback(void*)+1176) (BuildId: a6a5af21fb3cbca092466709df7030ac)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #29 pc 00000000000e7160  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36) (BuildId: b151e0103044156ae6597337e10f9e1b)
09-27 18:51:51.885 25167 25167 F DEBUG   :       #30 pc 0000000000085014  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: b151e0103044156ae6597337e10f9e1b)
09-27 18:51:52.391 24914 24914 I yoyo    : onPause
09-27 18:51:52.398 24914 24914 I yoyo    : Pausing the Runner
On the forum I saw someone having the same problem, but noone commented on that:
https://forum.yoyogames.com/index.p...ersion-2-3-0-release.78124/page-4#post-468996

We are using GMS 2.3.0.529 Runtime v2.3.0.401
When we turn off garbage collector with
gc_enable(false);
then everything works fine!
How can garbage collector crash with null pointer error?

In one week we must update our game on various mobile stores and now we don't know what to do!!!
Is it advisable to put
gc_enable(false);
in production and wait for Yoyo to fix this bug?

We are not using any struct or local functions or any of the new features. We only have those global functions, because on migration to GMS 2.3, GMS automatically wrapped all our scripts into functions.

This leads me to the conclusion that we are good to go for now with gc_enable(false);

Thank you in advance for any help!
 
Last edited:

SIG.

Member
We are not using any struct or local functions or any of the new features. We only have those global functions, because on migration to GMS 2.3, GMS automatically wrapped all our scripts into functions.

This leads me to the conclusion that we are good to go for now with gc_enable(false);
I would also like to know whether garbage collection can be safely turned off if none of the new features are being used outside of the import process that wraps scripts into functions.

Basically, does the new function system require the GC? I've seen contradictory statements in the forums. (There was a thread about ... well, I think the gist of it was that GMS creates a new object every time a function is called, and you need the GC to clean up those objects, but then @Nocturne said the new GC only cleans up the new data features like structs so shouldn't have anything to do with memory leaks caused by repeatedly calling functions. I could be butchering or misunderstanding this. Ah, **** it, after re-reading that thread I'm at'ing @Dan and @rmanthorp into here, someone from YYG really should clarify this. The manual is a bit ambiguous particularly if we're talking about the kind of "global" functions that result automatically from the 2.3 importer.)
 
Last edited:

Nocturne

Friendly Tyrant
Forum Staff
Admin
When disabling garbage collection, arrays that are no longer referenced by a variable will not be cleaned up.
Sorry, this is wrong!
Actually, this is correct... !

Strings and data structures and everything else work exactly as before, ie: GameMaker will clean them up automatically just as it has always done without the use of the new garbage collector. The GC is only for use with arrays, structs, and functions and currently affects nothing else. If you are not creating methods, structs or arrays then you can happily turn the GC off. Even if you ARE using these things, you can actually turn the GC on and off as required... for example, at the end of the room you turn it on, call the gc_collect() function, then turn it off again after a frame or two. ;)

This leads me to the conclusion that we are good to go for now with gc_enable(false);
From the sounds of things, this may be fine for your project, but with arrays being collected you might need to use the turn it on/turn it off again trick if possible.

EDIT: Edited due to updated information.


EDIT EDIT: See this post please! https://forum.yoyogames.com/index.p...eference-on-physics-object.79508/#post-472667
 
Last edited:

chamaeleon

Member
Sorry, this is wrong!

Arrays and strings and data structures and everything else work exactly as before, ie: GameMaker will clean them up automatically just as it has always done without the use of the new garbage collector. The GC is only for use with structs and functions and currently affects nothing else. If you are not creating methods or using structs then you can happily turn the GC off. Even if you ARE using these things, you can actually turn the GC on and off as required... for example, at the end of the room you turn it on, call the gc_collect() function, then turn it off again after a frame or two. ;)
So what you're saying is that I'm imagining running out of memory and crashing when I run a program with this code?
Create
GML:
gc_enable(false);
a = array_create(100000, 0);
alarm[0] = room_speed;
Step
GML:
a = array_create(100000,0);
Alarm 0
GML:
show_debug_message(gc_get_stats());
alarm[0] = room_speed;
Output
Code:
...
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 2, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 703,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 765,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 827,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 889,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 0, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 951,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 1013,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 1075,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 1137,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 0, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 1199,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 0, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 1261,0,0,1 ] }
...
Compare this with not running out of memory when gc_enable(true) is used
Code:
...
{ objects_touched : 3, objects_collected : 0, traversal_time : 1286, collection_time : 0, gc_frame : 900, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 3, objects_collected : 0, traversal_time : 1056, collection_time : 0, gc_frame : 960, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 3, objects_collected : 0, traversal_time : 1055, collection_time : 0, gc_frame : 1020, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 2, objects_collected : 0, traversal_time : 668, collection_time : 0, gc_frame : 1080, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 3,1,207,1 ] }
{ objects_touched : 3, objects_collected : 0, traversal_time : 1008, collection_time : 0, gc_frame : 1140, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 3, objects_collected : 0, traversal_time : 735, collection_time : 0, gc_frame : 1200, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 3, objects_collected : 0, traversal_time : 747, collection_time : 0, gc_frame : 1260, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 4, objects_collected : 2, traversal_time : 1323, collection_time : 0, gc_frame : 1320, generation_collected : 1, num_generations : 4, num_objects_in_generation : [ 3,1,207,1 ] }
{ objects_touched : 3, objects_collected : 0, traversal_time : 1108, collection_time : 0, gc_frame : 1380, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 4,1,207,1 ] }
{ objects_touched : 4, objects_collected : 2, traversal_time : 1369, collection_time : 0, gc_frame : 1440, generation_collected : 1, num_generations : 4, num_objects_in_generation : [ 3,1,207,1 ] }
...
As can be observed, num_objects_in_generation increases steadily when gc is off, and remains steady at a low number when it is on.

VM compilation only, Windows target.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
That's... interesting! And definitely goes against what I have been told... Might be worth filing a bug report about it.
 

Plura

Member
@chamaeleon
Thank you for pointing this issue with arrays.

Obviously we can’t just turn off GC like that, on the other hand, if we turn it on it crashes our game.
We are stuck with a new kind of dangerous bug in gms 2.3 (stable release). Not good, not good at all! :mad:
 

chamaeleon

Member
That's... interesting! And definitely goes against what I have been told... Might be worth filing a bug report about it.
I'm basically assuming they tied the array implementation to the garbage collection when they made changes to them.

From the release notes
All arrays are now 1D
  • However, they can actually now be chained, so you can create arrays three (or more) deep if you require by chaining the declaration - e.g. array[0][0][0]
  • The 2D array functions have now been deprecated, but if you have these in your 2.2.5 projects they will still work due to the compatibility layer
Whether this (the arrays relying on the new gc) is a mistake/bug introduced or a conscious implementation decision, I couldn't say.
 

chamaeleon

Member
Same result using YYC Windows compilation. HTML5 target does not appear to show the same effect (not an extensive test though). Perhaps due to relying more on Javascript garbage collection under the hood instead of a custom one.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Okay, so after chatting to the devs it appears that array ARE garbage collected, and I just wasn't informed about the change. :(

So, the GC now works on arrays, structs and functions. The rest should all work as before. I will edit my posts to clarify this too. Thanks for bringing it to my attention!
 

Tornado

Member
That is bad news!!! We are stuck now then!
@Nocturne Thank you very much for the clarification.
I'll try to finish the "test" project and send it to Yoyo.
We have a huge project, it took me 4 hours until now and I'll need some more hours to remove everything from the project that is not needed, to be able to send yoyo a small project by preserving the crash.
Hopefuly tonight I'll be able to finish it.
 

chamaeleon

Member
I kind of hate to be a stick in the mud, but instance creation and destruction also relies on the garbage collector.
Create
GML:
gc_enable(false);
alarm[0] = room_speed;
Step
GML:
for (var i = 0; i < 100; i++) {
    var inst = instance_create_layer(0, 0, "Instances", obj_blank);
    instance_destroy(inst);
}
Alarm 0
GML:
show_debug_message(gc_get_stats());
alarm[0] = room_speed;
With gc
Code:
{ objects_touched : 201, objects_collected : 0, traversal_time : 85, collection_time : 0, gc_frame : 300, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 202,0,207,1 ] }
{ objects_touched : 201, objects_collected : 0, traversal_time : 171, collection_time : 0, gc_frame : 360, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 202,0,207,1 ] }
{ objects_touched : 201, objects_collected : 0, traversal_time : 191, collection_time : 0, gc_frame : 420, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 202,0,207,1 ] }
{ objects_touched : 201, objects_collected : 0, traversal_time : 94, collection_time : 0, gc_frame : 480, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 202,0,207,1 ] }
{ objects_touched : 201, objects_collected : 0, traversal_time : 178, collection_time : 0, gc_frame : 540, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 202,0,207,1 ] }
{ objects_touched : 201, objects_collected : 0, traversal_time : 58, collection_time : 0, gc_frame : 600, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 202,0,207,1 ] }
Without gc
Code:
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 78133,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 84135,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 90137,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 96139,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 102141,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 0, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 108143,0,0,1 ] }
{ objects_touched : 0, objects_collected : 0, traversal_time : 0, collection_time : 1, gc_frame : 0, generation_collected : 0, num_generations : 4, num_objects_in_generation : [ 114145,0,0,1 ] }
With garbage memory remained at around 15MB for a VM build, without garbage collection the memory usage increased at a steady pace.

I can't say I'm surprised at it, given that instances are now supposedly implemented as structs or using structs for parts of their data.

Edit: obj_blank is an object without any events implemented.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
OKAY

Drumroll, please!

After a loooong chat with various people it appears there has been a complete breakdown in communication between the devs and the documentation department... Thankfully this isn't a common occurrence and equally thankfully it's been resolved now and I can give you the 100% complete definitive ultra mega absolute list of things the Garbage Collector touches:

*DISCLAIMER: Nothing is ever 100% definitive but it's as close as it gets for this release... ;) :p
  • Methods
  • Structs
  • Instances
  • Arrays
  • Sequences
  • Animation curves

Now, for instances, anim curves and sequences, you should still ALWAYS use the appropriate destroy functions, as they will NOT be garbage collected automatically. They are "first-class" assets, which means if you define one in code but don't use it, it's STILL taking up memory, much like a global struct or function. So when you call the destroy function you are de-referencing it completely for the GC to pick up.

I've previously said that data structures aren't garbage collected either, and you'll see that they aren't on my list above... HOWEVER, they may still need the GC if the contents of the DS are any of the items listed above. Storing a GC collectible asset or data type means that GameMaker has to track it somehow as part of the data structure, and it does this internally using a basic struct object (inaccessible to the user, part of the engine). This object will be garbage collected when the DS is destroyed and the GC is enabled. If the GC is NOT enabled, then it won't and you will get a very tiny memory leak, even though the data structure itself doesn't rely on the GC. (NOTE! this may be subject to change in future updates, but it's how it works right now).

Finally, the function gc_collect CAN BE CALLED WITH THE GC DISABLED. This means that you can disable the GC and then call the collect function at any time and the GC will run for a frame and do it's job without the need for it to be enabled and disabled again.

So, apologies to everyone that read any of my previous posts on this subject as they were incorrect and misleading, and the information here is correct for 2.3.0 and will be correct for 2.3.1 too.
 
Last edited:

kburkhart84

Firehammer Games
@Tornado in the other post you mention something about getting errors when using instance_destroy() in the room_end event. I'm not seeing anything about that specific detail here in this post. But, I will say that in general, if the room ends, the objects automatically get destroyed unless they are persistent. So you should not be trying to destroy objects there anyway. I'm guessing maybe pre-2.3 and pre-garbage collector times, those instance indices were still available, but now they are not, and so you get an error message when using instance_destroy() on objects that are already destroyed(or in the process of being destroyed). I could be wrong about it, but considering you say the errors go away with the garbage collector disabled, I'm guessing its the case.

I could suggest, if your game involves something like levels, where you change rooms often enough, that you simply disable the GC, and then run gc_collect() between rooms. This will let the performance glitch of the GC happen at a time when it doesn't matter, between levels, or whatever it is that applies to your game.
 

Tornado

Member
@kburkhart84 Yes, I was about to write about that in this thread. I'm still working for my regular job, so I can't do everything at once. :)
Thank you for your insights, this is exactly what I was going to post here. This probably resolves one crash (we are still testing, but it looks very promising).
Later I will file the bug report anyway, I think GC musn't crash because of this.

For the second crash we are still trying to find the problem, but it must be something similar, only for this crash we still didn't find an obvious instance_destroy() or similar.
We are working on it...
 

SnoutUp

Member
Thanks for this thread. I don't use physics engine and started having some crashes which look related to the garbage collection. One user also reported that game starts with black screen and not responding on a new phone, but that might be a separate issue.

GML:
  #00  pc 0000000000173718  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/split_config.arm64_v8a.apk (offset 0x103000) (MarkAndSweepGen(int, int, bool)+1300)
  #00  pc 00000000001746c0  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/split_config.arm64_v8a.apk (offset 0x103000) (DoGenerationalGC(int)+208)
  #00  pc 00000000002ab90c  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/split_config.arm64_v8a.apk (offset 0x103000) (DoAStep()+80)
  #00  pc 00000000002ac19c  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/split_config.arm64_v8a.apk (offset 0x103000) (MainLoop_Process()+1024)
  #00  pc 00000000003af854  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/split_config.arm64_v8a.apk (offset 0x103000) (Java_com_yoyogames_runner_RunnerJNILib_Process+868)
  #00  pc 0000000000071700  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/oat/arm64/base.odex (offset 0x70000) (com.yoyogames.runner.RunnerJNILib.Process+208)
  #00  pc 00000000000d510c  /data/app/com.snoutup.cardhog-TLezjKOTwOYpSYYbyXOqjw==/oat/arm64/base.odex (offset 0x70000) (com.snoutup.cardhog.DemoRenderer.onDrawFrame+732)

Now, can somebody recap what will happen if I'll just do gc_enable(false)? I'm already destroying my structs and objects, got very few small arrays and use none of the new stuff. Should be fine?
 

Plura

Member
Our team will do their best and investigate what ruins the garbage collector.
We have to do it for the sake of our project and we are ready to share all the experience with all the game maker friends here.
If there is a bug with GC, we will make a sample project and submit it to yoyo.
We'll get back to you soon!
 

kburkhart84

Firehammer Games
We have to do it for the sake of our project
Does 2.3 fix something that 2.2.5 had messed up? Otherwise, what's forcing you to upgrade to 2.3 for your project? Usually it is best to not upgrade IDE versions in the middle of important projects unless they are minor updates due to exactly this kind of issue, and despite it being 2.3 and not 3.0, it is NOT a minor update.
 

SnoutUp

Member

I personally would still be on 1.4 if nothing would force me to upgrade.

Does 2.3 fix something that 2.2.5 had messed up? Otherwise, what's forcing you to upgrade to 2.3 for your project? Usually it is best to not upgrade IDE versions in the middle of important projects unless they are minor updates due to exactly this kind of issue, and despite it being 2.3 and not 3.0, it is NOT a minor update.
 

Plura

Member
@kburkhart84
There were tough times for our team in the era of game maker studio 1.x. We were far behind because of the esoteric spine changes and other bugs that drove us crazy.
We export to almost all platforms except game consoles (Nintendo, Sony, and Microsoft). We export to literally all other platforms, and even Linux export is very important to us.
The more platforms you have the more bugs you find.
If we do not go strongly forward we lose control of what yoyo is doing since we export to many platforms. At the moment we think we are safe a big problem like this can happen:
https://www.reddit.com/r/gamemaker/comments/4qiqon When you a lot behind the current stable version than your reaction time is gone. If something happens and yoyo has to release a quick hotfix. Your project can easily die.
I have been working in a game maker for 7 years and I will never do the same mistakes again.
I'm just bothered by serious bugs in stable versions nothing else.
Everyone has its own way of succeeding. My way is to keep up with the newest stable versions.
Being passive is not good for business in my case. I have already learned my mistakes.
However, GC should not break an app in its stable release.
 

kburkhart84

Firehammer Games
I'm just bothered by serious bugs in stable versions nothing else.
...
However, GC should not break an app in its stable release.
100% I agree, I don't think 2.3 was ready for "stable" honestly, I think they rushed it due to how much pressure they may have been getting from everybody to release.

Everyone has its own way of succeeding. My way is to keep up with the newest stable versions.
Being passive is not good for business in my case. I have already learned my mistakes.
I too have the general habit of staying up with the stable versions. But after all this time I don't have any big projects going. If I did, I would likely hold off on any major upgrades until they were in better shape. I'm currently finishing up a rewrite of my input system asset however which is indeed to "keep up" with things. I think its good to keep up, but I don't think its good to force a big project onto a new version when that new version is simply not ready. The only reason it would be worth it is if that version had something you needed, either a new feature, or a bug fix, like SnoutUp mentioned. Otherwise, its better to keep the project in the old version to make sure you can easily finish and release.
 

Tornado

Member
@kburkhart84 It is hard to find the right time for migration if your app is already live. It means that you are never "finished" with the project and a good time for migration would be exactly NEVER! We are keeping eye on 2.3 from the beginning of the Beta phase. If you want to keep your app alive you have deliver updates because of bugs or to improve according to users' feedback. So we MUST be able to build for ALL mobile plafforms anytime!!!
With new iOS and Android coming we have to be prepared for that, otherwise we won't be able to build. Be aware that we have a big project, it is not a toy. It takes weeks to test everything in the game. There is AI involved and there are countless different scenarios in the game. You cannot wait fo the moment where everything changes because it will be a big mess. So we had to migrate to 2.3 to have enough time for 2.3 adjustments and intensive testing before big platforms (Apple, Google) hit us with their changes.
Unbenannt.JPG
Staying on 2.2 is too risky now, we have to be ready for the new XCode 12. If one stupid thing is not working between GMS -> MacBook -> XCode you are screwed!
On top of that we manually integrate/inject libraries for Ads mediation...for Android and iOS.
Those who never developed for mobile platforms from gereric Framework (GMS) don't know what nightmares you have to go through.
We also need to spend some time with 2.3 to identify all problems...this can take weeks until "everything" is identified.
Our game is using physics engine exensively on very high level. Only a fraction of GMS users use physics engine on that level. If we wait for all bugs to be reported to YOYO we could wait until the end 2025. We have to identify the problems by ourselves and report it to YOYO. I can go on and on.....but no time for that.

So, again we are not doing this for fun, but because we must and because we decided that the time for us IS NOW!
 

kburkhart84

Firehammer Games
@Tornado That answers my question, though I hadn't directly asked you. I'm just curious why people are rushing to update when it isn't generally the best idea. It seems multiple people mention that macOS issue as well(not sure why you put it in such big text either, you seem almost defensive when you haven't done anything wrong).

In any case, I understand how for some people there is a need to stay right on top of things, and mobile is different like that from typical PC games, I know.
 

Tornado

Member
I found the time to answer your question. I think you should appreciate that and not stick to the detail why the picture is so big. I just did a screenshot, copy&paste and it just got that big. no big deal.
No need to analyze my psychological profile. :cool:
LOL
 

kburkhart84

Firehammer Games
I found the time to answer your question. I think you should appreciate that and not stick to the detail why the picture is so big. I just did a screenshot, copy&paste and it just got that big. no big deal.
No need to analyze my psychological profile. :cool:
LOL
No worries, and the reason I acknowledged your response was because I honestly DO appreciate it. I just wasn't sure if you had taken issue with me asking or something like that. Better safe than sorry I guess.
 

Plura

Member
We have an announcement about the new garbage collector.
Our small test project can reproduce the application crash caused by GC. My colleague @Tornado will soon put a link for download.
He will also explain in detail when this issue happens. I hope this will help many people on how to avoid crashes in gms 2.3.0.
 

Tornado

Member
We managed to do a minimal project which can reproduce Garbage Collector crash!
We can confirm that doing
instance_destroy();
in the "Room End Event" is causing Garbage Collector to crash the game!
When we turn off Garbage Collector then there is no crash.

We know that all objects in the room are automatically destroyed when room is left, but we have some "legacy" code in our project, as it is over 6 years old and several developers worked on it from the very beginning until now.

Anyways, GMS 2.3 and Garbage Collector MUST NOT crash (null pointer dereference) the game because of this!!!

The crash happens at least on Windows and Android platforms no matter if VM or YYC.
iOS we didn't check yet, but I guess it will be the same.

Here is the demo project:
https://www.dropbox.com/s/dlbwgu4c3as5o8j/GC_bug.zip?dl=0

Just start it and then just click with the mouse anywhere in the game (or tap for mobiles).
Please try this demo project if you can and confirm the crash here.

If you comment out this line:

p1.jpg

or turn off the garbage collector by uncommenting this line:

p2.jpg

then the game won't crash.

For all of you having those misterious GC crashes after migration to GMS 2.3.0, check all of your Room End events and in general check carefully places where you explicitly destroy objects. If you have too many Room End events, you can list them all via search in Windows Explorer. Just search for files named Other_5.gml. That way all room end events will be listed and then you can open one by one with the editor and check if they contain any instance_destroy(); (But do not edit and save in that editor if it is not set to UTF-8 encoding :), do it rather directly from GMS)
 
Last edited:

chamaeleon

Member
I managed to reproduce the crash using the project from dropbox. Starting the program in GMS, then opening up Visual Studio 2019, selecting Debug->Attach to Process and selecting the executable (either YYC compiled exe, or Runner.exe for VM), and clicking inside the game window results in exceptions like the one below, clearly some mismanaged memory somewhere.

GC-Bug-1.PNG
Seems like it should be easy enough YYG to also replicate the bug using the project, assuming it's submitted to them.
 

kburkhart84

Firehammer Games
I'm not sure if this is something that we are going to have to get used to, or if they will fix it. If the room ends, you shouldn't really have to call instance_destroy() because the object will be destroyed anyway, so there isn't really any point in destroying it since it will already be getting destroyed. I'm guessing that somehow there is a difference in behavior with the garbage collector.

This post is not defending them in any way, just noticing that the call to instance_destroy() that is causing the crash is really redundant anyway, so they may decide to say that you shouldn't be doing it instead of changing their internal code to fix the issue.
 

SnoutUp

Member
And this is something good IDE should warn about or engine should just ignore.

Either way, this discovery doesn't help me much, because I have no room end events, but hopefully it will help YYG to find and fix the issue.

I'm not sure if this is something that we are going to have to get used to, or if they will fix it. If the room ends, you shouldn't really have to call instance_destroy() because the object will be destroyed anyway, so there isn't really any point in destroying it since it will already be getting destroyed. I'm guessing that somehow there is a difference in behavior with the garbage collector.
 

Alice

Toolmaker of Bucuresti
Forum Staff
Moderator
For the record: before the Clean Up event was introduced and objects weren't destroyed automatically on room end, there was a very legitimate use case for calling instance_destroy(); for each instance in the room, since that's where the data structures cleanup would go.

Now? Probably not so much, but I agree that re-destroying the object on room end should be neutral rather than cause a crash. Especially considering the possibility of objects destroying themselves or each other in events other than Room End, that just happen to be launched on room end.
 

Tornado

Member
Either way, this discovery doesn't help me much, because I have no room end events, but hopefully it will help YYG to find and fix the issue.
Sorry to hear that! :-(
Try to crash your game so many times possible in Android VM and EVERYTIME check the crash stacktrace in GMS output console if you will get more information above the
(MarkAndSweepGen(int, int, bool)+1300)
line.
I noticed for example that not everytime i get the message "null pointer dereference".

We had a huge luck to have this above MarkAndSweepGen on the Android run
Code:
(b2Fixture::Destroy(b2BlockAllocator*)+28) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
(b2World::DestroyBody(b2Body*)+336) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
(CPhysicsObject::~CPhysicsObject()+112) (BuildId: 7a51802fbe6f0c6fe2b49dd80e9c2b426afcfa8e)
which pointed us in the instance_destroy() direction.
Otherwise we would still be leaping in the dark!

With Windows VM you get ABSOLUTELY NOTHING on the console, it just crashes silently and perfidiously!

Sorry I cannot help you more!
 

gnysek

Member
Now, for instances, anim curves and sequences, you should still ALWAYS use the appropriate destroy functions, as they will NOT be garbage collected automatically
That would mean that after switching to next room instances remains in memory (even if previous was non-persistent), so is this really true ?

I think we would need some blog post about that.
 

kburkhart84

Firehammer Games
For the record: before the Clean Up event was introduced and objects weren't destroyed automatically on room end, there was a very legitimate use case for calling instance_destroy(); for each instance in the room, since that's where the data structures cleanup would go.

Now? Probably not so much, but I agree that re-destroying the object on room end should be neutral rather than cause a crash. Especially considering the possibility of objects destroying themselves or each other in events other than Room End, that just happen to be launched on room end.
Since when were instances not automatically destroyed(except persistent ones) when you change rooms? Was it before GM7? I've never had to worry about destroying them. Yes, data structures etc... need cleaned up, which we normally did on either game end or the object destroy event, but manually destroying instances when changing rooms?

Now, we DO agree that redestroying the object that just be neutral, even it has always been a redundant call that used to just be neutral before. But I don't know if they will acknowledge that or just tell us that we shouldn't be removing instances that are already destroyed or in process of being destroyed already.
 

Alice

Toolmaker of Bucuresti
Forum Staff
Moderator
Since when were instances not automatically destroyed(except persistent ones) when you change rooms? Was it before GM7? I've never had to worry about destroying them. Yes, data structures etc... need cleaned up, which we normally did on either game end or the object destroy event, but manually destroying instances when changing rooms?
When you change rooms, the non-persistent instances were removed from the game, but they weren't destroyed in a way that invokes Destroy event.
Thus, if you followed a basic "create DS on Create, free DS on Destroy" pattern, you needed to ensure the Destroy event is called - otherwise there would be leak for removed-not-destroyed objects. This is also a likely reason why separate Clean Up event was added at some point in GM:S lifetime.

Whether instances now all invoke Destroy event on room end or not, I don't know. As I see it, they shouldn't, to stay consistent with the usual applications of Destroy and Clean Up events. To quote the docs:
Destroy
This event is the event to be executed when an instance is destroyed. It is often overlooked when adding behaviours to objects, but it can be very useful, for example by creating explosion or particle effects when an enemy is killed, or for re-spawning a new instance of the object in another part of the room, or even for adding points onto a score.

Clean Up
This event will be called after any event that removes an instance of the object from the room. So, it will be triggered if the instance is destroyed, if the room ends, or if the game ends, and is designed for you to use to "clean up" any dynamic resources that you may have in your game (like surfaces, data structures, etc...) or to perform any task that you need performed once when the instance is removed. [...]
Going by example use-cases, Destroy Event is meant to be used at something like entity's death/demolition/etc. which creates various kinds of audiovisual effects and affects game progress/score/whatever.
Clean Up Event, on the other hand, is meant to be used whenever the instance is removed from game's memory, which requires freeing all manually managed resources belonging to that instance.
You may notice that docs mention destroying he instance as one of multiple reasons of removing the instance (the others being room end and game end).
 

kburkhart84

Firehammer Games
When you change rooms, the non-persistent instances were removed from the game, but they weren't destroyed in a way that invokes Destroy event.
Thus, if you followed a basic "create DS on Create, free DS on Destroy" pattern, you needed to ensure the Destroy event is called - otherwise there would be leak for removed-not-destroyed objects. This is also a likely reason why separate Clean Up event was added at some point in GM:S lifetime.
Indeed, I assume that is why the Cleanup event was added, and indeed that would be where you put the destroying of things you have to manually destroy, like data structures. However, I'm still not sure why you would want to destroy an object in that event, as the object is already being destroyed. I still think it should just not have an effect if you do, but it IS a valid excuse that Yoyo may use instead of actually fixing the issue.
 

Alice

Toolmaker of Bucuresti
Forum Staff
Moderator
However, I'm still not sure why you would want to destroy an object in that event, as the object is already being destroyed.
I'm not sure what do you mean by "that event", so I'm going to assume it's the Cleanup event.
However, I never talked about destroying objects in the Cleanup event specifically - I would never dream of it - but rather in the Room End event.

The thing is, before Cleanup event was added, there was still a need for calling cleanup code somewhere for the instance. Destroy event seemed like the most appropriate option.
However, Destroy event was invoked only by explicit instance_destroy() call - non-persistent instance being removed from the game when leaving the room would not have its Destroy event called.
That's why - again, before Cleanup event was added - in order to reliably call the cleanup code, I needed to call instance_destroy() for all remaining non-persistent instances. If not for that, their Destroy event wouldn't be called, the instances would become lost and their resources would remain unfreed.

Of course, now that we have the Cleanup event, this scenario of destroying an instance on Room End becomes unnecessary.
Still, there can be other scenarios where someone needs to enforce Destroy event side effects at Room End, or situations where seemingly unrelated instance-destroying code coincides with leaving the room. Who knows?
 

kburkhart84

Firehammer Games
Of course, now that we have the Cleanup event, this scenario of destroying an instance on Room End becomes unnecessary.
Still, there can be other scenarios where someone needs to enforce Destroy event side effects at Room End, or situations where seemingly unrelated instance-destroying code coincides with leaving the room. Who knows?
It wasn't you specifically that destroys instances in the roomend or cleanup event...it is someone else in this post, Tornado, that is reporting a bug, that is being caused by destroying the instance in the room end event(not sure where exactly we went from cleanup to room end, wouldn't be surprised if both had the same bug if you destroy the instance in either one as it is already in progress). It doesn't make sense to call instance_destroy() in either of those events because the object is already being destroyed, and any code that you need to run regardless of how it gets destroyed would be best in the cleanup event to be sure it actually gets called.

Still, there can be other scenarios where someone needs to enforce Destroy event side effects at Room End, or situations where seemingly unrelated instance-destroying code coincides with leaving the room. Who knows?
If there such a scenario, I don't know of any. The cleanup event should happen whether the instance was properly destroyed or if it was done by the room/game ending, and should be all that is needed for the purpose of cleaning up allocated stuff that the garbage collector won't handle. I would think that the only stuff that should be in the actual Destroy event are things that happen when the gameplay continues on in the same room, like adding an object for an explosion, or a dead remains version, or something like that....but nothing that is for doing cleanup should be there ever since the cleanup event was added back when.

The point I'm making is that since you shouldn't really be destroying the instance in its own events that are caused when it already gets destroyed, I think that Yoyo is going to tell us to simply not do it, instead of making sure that instance_destroy() doesn't cause an error in these cases.
 

Tornado

Member
@kburkhart84 By now we aready know that in normal case it it redundant to call instace_destroy() in Room End event. This is nice when you start writing new code and can organize your code around that concept.
But if you have tons of old code which followed some older pattern or lack of knowledge at that time, yoyo MUST ensure that older code do not break by crashing the application. It is easy for us to be smart now.
If they don't do that they can't be taken as serious company. For Gods sake it is not forbidden or a crime to call instance_destroy() in Room end event so that you will be punished by a silent crash.
I don't know why are you repeatedly speculating what is yoyo going to tell us.
We did our "job" (3 people each around 3-5 days) , now they should do theirs.
I submitted a (heavy) BUG, we are waiting now for their reaction.
 

kburkhart84

Firehammer Games
yoyo MUST ensure that older code do not break by crashing the application.
That's funny...they will do what they want whether you like it or not. I'm not disagreeing that it should be fixed, but if they don't it will be up to YOU to fix your code. Whether we like it or not, this version is not a minor upgrade, and whether we like it or not, even minor updates sometimes break code and projects that were done in previous versions.

As far as me speculating...there is no reason I can't speculate. I have the right to do so, its a public forum. You ALSO have the right to share your opinion, even if it disagrees with mine.

Whether you like it or not, its best to be prepared for whatever outcome you get. Hopefully my speculation is wrong and they simply fix it, but if it were me in your place, I'd be prepared to just remove instance_destroy() from my room_end events and move things around as needed. I'm not saying it won't be painful, but it may be what you are stuck with.
 

Tornado

Member
Dude, we were not born yesterday. No one said that we won't adjust our code. Of course we must remove instance_destroy() from couple of places anyway, but this is no guarantee that GC will not break somewhere else.
And it is not only about us. I could easily leave this thread and not submit the bug, because with adjustements it works for us now.
So it is important to submit that bug, so they can see they have one or even more big holes in the garbage collector. There are people reporting GC crash without having Room End events in the project. So, big picture please!
 

kburkhart84

Firehammer Games
Dude, we were not born yesterday. No one said that we won't adjust our code. Of course we must remove instance_destroy() from couple of places anyway, but this is no guarantee that GC will not break somewhere else.
And it is not only about us. I could easily leave this thread and not submit the bug, because with adjustements it works for us now.
So it is important to submit that bug, so they can see they have one or even more big holes in the garbage collector. There are people reporting GC crash without having Room End events in the project. So, big picture please!
That's good. I never said the bug report shouldn't be submitted. I was just hoping you didn't fully expect it to be fixed, and your tone as far as "they MUST" wasn't going to fly to make them actually fix it. That said, code breaking changes are going to happen, so big-picture, people need to be used to that if they can't stay on the older version for their project(like in your case).
 

TsukaYuriko

🌠
Forum Staff
Moderator
Topic cleaned. I know discussions about the future and current state of GM can get a bit exciting and heated, but please try to stay constructive and objective. ;) Speculation about GMS features, YoYo Games' policies or what YoYo Games may or may not be telling its users to do is against the rules, so please cease that as well.
 

SnoutUp

Member
That's good. I never said the bug report shouldn't be submitted. I was just hoping you didn't fully expect it to be fixed, and your tone as far as "they MUST" wasn't going to fly to make them actually fix it. That said, code breaking changes are going to happen, so big-picture, people need to be used to that if they can't stay on the older version for their project(like in your case).
I'm genuinely confused about your role in this thread. If it's to test patience of developers who have serious issues caused by a stable GameMaker release they were forced to upgrade to and dare to expect a decent level of support... then you're doing a great job! However I'd rather see more information on the topic itself.
 

kburkhart84

Firehammer Games
I'm genuinely confused about your role in this thread. If it's to test patience of developers who have serious issues caused by a stable GameMaker release they were forced to upgrade to and dare to expect a decent level of support... then you're doing a great job! However I'd rather see more information on the topic itself.
Tornado in the other post you mention something about getting errors when using instance_destroy() in the room_end event. I'm not seeing anything about that specific detail here in this post. But, I will say that in general, if the room ends, the objects automatically get destroyed unless they are persistent. So you should not be trying to destroy objects there anyway. I'm guessing maybe pre-2.3 and pre-garbage collector times, those instance indices were still available, but now they are not, and so you get an error message when using instance_destroy() on objects that are already destroyed(or in the process of being destroyed). I could be wrong about it, but considering you say the errors go away with the garbage collector disabled, I'm guessing its the case.

I could suggest, if your game involves something like levels, where you change rooms often enough, that you simply disable the GC, and then run gc_collect() between rooms. This will let the performance glitch of the GC happen at a time when it doesn't matter, between levels, or whatever it is that applies to your game.
That was my first post in the thread. It contained a valid solution to workaround the problem without fully sacrificing the GC's benefit

I'm not experiencing the problem because I don't have mobile projects like you guys that are forcing the update(though I AM using it). Eventually it piqued my curiosity and I too wanted information on the topic(why people were forced to upgrade, as I know mobile stuff can change fast but usually its not quite that fast), and I also mentioned how the issue creating the error was technically something that is not necessary to do anyway(destroying an instance in a room end event since its already being destroyed).

Basically, since I'm not directly experiencing it, I'm providing an (obviously unwelcome by some people) 3rd party point of view. Some people seem to get upset by it, and I understand it with the frustration they are experiencing. I'm sorry if that isn't enough of a reason to chime in on a thread in your point of view.
 
Last edited:
Top