• Hey! Guest! The 37th GMC Jam will take place between May 28th, 12:00 UTC and June 1st, 12:00 UTC. Why not join in! Click here to find out more!

Windows Crash Without Error Report and Copying to a New Source File

Howdy all!

I have a question concerning my game GunDown.

I noticed that in (to my knowledge it only happens in) world 3 on any stage that very rarely, the game crashes when you go to the shop. Straight up shuts down. It does not freeze. It does not report any error. The problem is: GunDown is randomly generated. VERY randomly generated. And (lesson learned) when I created the engine for my game I neglected to add seeding. I'm virtually too far down the road to add seeding (post-release) so I'll just have to make it a lesson for later. The problem this causes is that I cannot test the issue. It is totally random whether the crash happens or not and it seldom happens. Like, for as many times as I've played through the game and gone to the shop and played in World 3, the game has only crashed maybe 4 or 5 times without a report, each time being related to this behavior.

So here's the thing: from my experience of making games in GameMaker, I've known the program to freeze if you have an infinite loop (duh), fail to start and throw a compiling error, crash and tell you the game ran out of memory, or crash and return an error report. Additionally, on insanely rare occasions, I've had a game crash without any indication of what went wrong. This has only happened in two of my projects and they were both my longest running and largest projects: GunDown and another un-released game that I quit making. With the latter, I fixed the issue, but I don't even remember how and I'm not sure I even understood why what I did fixed it.

Question 1: My assumption is that my project corrupted somewhere. Considering the game doesn't freeze, I assume it's not an infinite loop. Considering the game doesn't return an error message, I'm guessing I don't have a code problem (I could be wrong, though). And considering it doesn't say it ran out of memory, I would think it doesn't have anything to do with, well, running out of resources. Am I somewhat accurate in assuming this? Does someone have any knowledge on a game suddenly shutting off?

With that assumption, I decided to import everything into a fresh, empty project file. I did this by exporting all the resources into an extension and importing them into the new project file. The game compiles and runs fine though I haven't tested for the crash yet (which will be an ordeal to do).

Question 2: Will exporting into an extension and importing the files into the new project carry the corruption with it? Or is there no way to know?

My guess is it depends if the corruption is within an object or within some underlying piece of the project whether or not this will actually resolve the issue.

UPDATE:
Exporting into an extension and importing the files into the new project did not fix the crash.

UPDATE 2:
It appears to be related to a while loop after all. I fixed one loop that was crashing it, but I seem to have something else crashing as well. Will update with a solution later on. (If I can find one)

Thank you in advance and let me know if you have any questions,
~Gravityhamster
 
Last edited:
I know you're supposed to wait 48 hours to bump, but I found an interesting piece of information on the issue. I was looking through my appdata and found a bunch of crashdumps from this evening's testing.
If you look under "Exception Information", you can see "The thread tried to read from or write to a virtual address for which it does not have the appropriate access." I wonder if this means anything... By the way this is GameMaker 1.4.1804.
upload_2020-2-14_23-35-2.png
 

FrostyCat

Member
Can't you make a fork of your project and just stick random_set_seed() where you already have randomize()? Just because your game is already post-release, it doesn't mean your project is past the point of debugging. And if your project isn't set up with source control to safely allow this kind of exploration, that in itself is an issue.

By the way, had you set up your abandoned but fixed project with source control, checking through its history logs or doing a bisect would have also allowed you to track down the fix.

On top of that, try 1.4.9999. This is the last version of GMS 1.4, and may have fixed the problem there in the meantime. Don't expect YoYo support at this point, though.
 
Can't you make a fork of your project and just stick random_set_seed() where you already have randomize()? Just because your game is already post-release, it doesn't mean your project is past the point of debugging. And if your project isn't set up with source control to safely allow this kind of exploration, that in itself is an issue.

By the way, had you set up your abandoned but fixed project with source control, checking through its history logs or doing a bisect would have also allowed you to track down the fix.

On top of that, try 1.4.9999. This is the last version of GMS 1.4, and may have fixed the problem there in the meantime. Don't expect YoYo support at this point, though.
Thank you for your response,

Yes, but I used the randomize command throughout the project and it would take quite a bit to track down each randomize to change to random_set_seed() unless there is some other way I don't know of. I suppose it could be worth it in the long run.

As for source control, no I did not have that set up.

Finally, as for upgrading to GameMaker 1.4.9999, I will try that tomorrow or as soon as I get the chance.

Thanks again.
 

Nidoking

Member
If nothing else, you don't want to call either randomize or random_set_seed more than once per run of your game. Calling random_set_seed again will just reset the sequence of pseudo-random numbers. That won't be what's causing your problem, but it makes it harder to debug, as you're discovering.
 
If nothing else, you don't want to call either randomize or random_set_seed more than once per run of your game. Calling random_set_seed again will just reset the sequence of pseudo-random numbers. That won't be what's causing your problem, but it makes it harder to debug, as you're discovering.
Yeah. I know the documentation said you only need to call randomize once, but for some reason, I remember finding that if I only called it once in an object, I still found that I would get the same results in other objects. At least, I'm pretty sure. I could be wrong.
 

FrostyCat

Member
If nothing else, you don't want to call either randomize or random_set_seed more than once per run of your game. Calling random_set_seed again will just reset the sequence of pseudo-random numbers. That won't be what's causing your problem, but it makes it harder to debug, as you're discovering.
Sometimes you do want to temporarily reset the seed mid-game, for example with level generation. It's not hard to debug as long as the number of places this is done in is limited, and you have a firm grasp of how code is ordered in GM.

Yeah. I know the documentation said you only need to call randomize once, but for some reason, I remember finding that if I only called it once in an object, I still found that I would get the same results in other objects. At least, I'm pretty sure. I could be wrong.
You are most certainly wrong. The Manual said to run randomize() once, but it also said to do it at the very beginning of the game, not just in any arbitrary object.
The Manual entry for randomize() said:
Should you wish to test with true random, you should call this function at the start of your game.
When you disobeyed the Manual and called the function once but late, you found yourself at the mercy of the instance creation order. Every instance that comes before the randomize()-calling instance would get a fixed sequence instead of a truly randomized sequence. Had you made sure randomize() came absolutely first by setting it apart in time from everything else that could depend on it, this instance-on-instance rat race would have been none of your business.
 

MaxLos

Member
Yes, but I used the randomize command throughout the project and it would take quite a bit to track down each randomize to change to random_set_seed() unless there is some other way I don't know of. I suppose it could be worth it in the long run.
Just wanted to add that you can press Crtl + Shift + F to search for terms in your entire project
 
So I followed your guys' advice, but something isn't right... I commented out "randomize();" from every part of the game. I've double checked and triple checked and they are all commented out. I am not running any kind of code to generate a seed now. I'm just running the game and then running the random command and displaying it to the screen along with the seed (I used random_get_seed here to show the seed). I ran the game twice and took a screenshot of the results and here's what I got:
upload_2020-2-15_18-11-30.png
The seed in both cases (obviously) is zero, but random is returning an entirely different number. Why? According to the manual:
The Manual said:
NOTE: When using the random functions, GameMaker: Studio maintains the same random seed every time you start the game. This makes debugging much easier as you are guaranteed that the random functions will always return the same value, however should you not wish this to happen, you must first set a new random seed at the very start of the game, either using randomize or random_set_seed.
By this statement, should not the number be the same?
 

FrostyCat

Member
So I followed your guys' advice, but something isn't right... I commented out "randomize();" from every part of the game. I've double checked and triple checked and they are all commented out. I am not running any kind of code to generate a seed now. I'm just running the game and then running the random command and displaying it to the screen along with the seed (I used random_get_seed here to show the seed). I ran the game twice and took a screenshot of the results and here's what I got:
View attachment 28776
The seed in both cases (obviously) is zero, but random is returning an entirely different number. Why? According to the manual:

NOTE: When using the random functions, GameMaker: Studio maintains the same random seed every time you start the game. This makes debugging much easier as you are guaranteed that the random functions will always return the same value, however should you not wish this to happen, you must first set a new random seed at the very start of the game, either using randomize or random_set_seed.

By this statement, should not the number be the same?
Not if the number of random-dependent calls doesn't exactly match between the two executions. This happens a lot when human reflexes get mixed into an environment filled with random-dependent gameplay elements.

The Manual says that if you start from a fixed seed, the sequence of random outputs from it will be an identical sequence every time. Let's notate this sequence as A, B, C, D, etc. Whenever you call a random-dependent function, you get the next value in the sequence and transform that into the kind of output that the function would normally return. For example, if random(1900092) is the first random-dependent function to run, then it will pull A, transform that to the [0, 1900092) range and return the result. The next random-dependent function will then pull B and transform it, and so on.

Now here's the insidious part most people on the GMC don't know. Aside from direct sources like random(), there are also indirect sources like ds_list_shuffle() or even more implicit sources like particle emitters. So if you do stuff like allowing a generator or particle system to run even one step more or less because of keystroke delays, you will start pulling values off a different place in the sequence going forward. And if the PRNG is worth its salt, two different places in the sequence have an overwhelming chance of being different. Unless your test runs are fully automated or the sampled value is the immediate thing after random_set_seed(), you have a near-zero chance of an exact line-up.

I hope the developers at YoYo would hear this argument against the "fixed seed helps debugging" myth, especially @Nocturne who is responsible for the Manual perpetuating it. A fixed seed set only once at the beginning of the game is completely unhelpful in debugging most conventionally developed projects.
 
Not if the number of random-dependent calls doesn't exactly match between the two executions. This happens a lot when human reflexes get mixed into an environment filled with random-dependent gameplay elements.

The Manual says that if you start from a fixed seed, the sequence of random outputs from it will be an identical sequence every time. Let's notate this sequence as A, B, C, D, etc. Whenever you call a random-dependent function, you get the next value in the sequence and transform that into the kind of output that the function would normally return. For example, if random(1900092) is the first random-dependent function to run, then it will pull A, transform that to the [0, 1900092) range and return the result. The next random-dependent function will then pull B and transform it, and so on.

Now here's the insidious part most people on the GMC don't know. Aside from direct sources like random(), there are also indirect sources like ds_list_shuffle() or even more implicit sources like particle emitters. So if you do stuff like allowing a generator or particle system to run even one step more or less because of keystroke delays, you will start pulling values off a different place in the sequence going forward. And if the PRNG is worth its salt, two different places in the sequence have an overwhelming chance of being different. Unless your test runs are fully automated or the sampled value is the immediate thing after random_set_seed(), you have a near-zero chance of an exact line-up.

I hope the developers at YoYo would hear this argument against the "fixed seed helps debugging" myth, especially @Nocturne who is responsible for the Manual perpetuating it. A fixed seed set only once at the beginning of the game is completely unhelpful in debugging most conventionally developed projects.
Thank you. This was very helpful and informative. It seems that statement from the manual is a little misleading then.

Back to the original problem that I posted about: I updated GameMaker to 1.4.9999 and have yet to experience the crash. However, it may be to soon to tell. I will edit this message later on.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
I hope the developers at YoYo would hear this argument against the "fixed seed helps debugging" myth, especially @Nocturne who is responsible for the Manual perpetuating it. A fixed seed set only once at the beginning of the game is completely unhelpful in debugging most conventionally developed projects.
Tbh, I agree with this, but the manual contents are not up to me... I have to write what I'm told!!! However, I know that I (and I think everyone that understands this) automatically add randomize() to the start of all my projects because of it and as such I do think it's something that YYG should revist and discuss. Feel free to file a bug report requesting that the decision be revised.
 

FrostyCat

Member
Tbh, I agree with this, but the manual contents are not up to me... I have to write what I'm told!!! However, I know that I (and I think everyone that understands this) automatically add randomize() to the start of all my projects because of it and as such I do think it's something that YYG should revist and discuss. Feel free to file a bug report requesting that the decision be revised.
Done. For posterity, here is the text of my request:
Randomize the initial seed by default

===

Going forward, please randomize the the random seed by default, and remove all mentions of "fixed seeds help with debugging" from the Manual. The fixed random seed is a false cure for debugging projects that use particle systems or PRNG-dependent generators that run every step, because even the slightest delays in human input can cause a divergence in random outcomes. It has also been a constant source of confusion for new users who have yet to implement either of the above, but try random-dependent functions only to unexpectedly see a fixed outcome time and time again. The fixed debugging seed is completely unhelpful for users new and old, and is a decade-old decision that should be reversed in due course.

===

For one, it would reduce boilerplate code that virtually all GMS 2 projects now insert to counteract the fixed seed. Virtually nobody found it useful, while many people found it counterproductive.

In addition, there is mass confusion for new users on the GMC over why random functions don't seem random at first and also when to call randomize(). On the new GMC alone, there are more than a dozen Google result pages related to this:

https://www.google.com/search?q=randomize+same+site:forum.yoyogames.com

The most recent topic further demonstrating misconceptions over the fixed random seed is in the "Further Information URL" field.

All of this would be preventable had the initial seed been randomized. A fixed debugging seed is a tiny minority use case, and should be inserted on-demand and only where explicitly requested (e.g. middle of the game just before a level generator), not once at the beginning by default for everyone.

===

https://forum.yoyogames.com/index.php?threads/crash-without-error-report-and-copying-to-a-new-source-file.72149/#post-425413
 
Top