Graphical Object Global Reference

[Mithran]

Graphical Object Global Reference VX​

(game.exe crash debugger)​

by Mithran​

NOTICE: This is the VX version of the script. For the VX ACE Version go HERE​

Introduction

Getting seemingly random and yet occasionally predictable Game.exe crashes?
"Game.exe has encountered a problem and needs to close"

This is one of the most frustrating errors to deal with in RPG Maker VX as it seems to come and go at random, only affecting certain people or setups, and the actual cause of the error is hidden to you.

If your project is getting persistent Game.exe crashes or even occasional Game.exe crashes across more than one system, this may be worth a read. Hell, even if its not, it might still be worth a look. This script addresses one specific issue that can cause an unhandled exception leading to an eventual Game.exe crash. Your mileage may vary.

Spoiler

The cause of a given Game.exe crash could be any number of things - anything that
doesn't create throw an error in Ruby, but causes an unhandled exception in one
of the 'hidden' classes.

After extensive testing, I was finally able to recreate the circumstances leading
up to one such exception that, if left unhandled, could lead to Game.exe crash.

1. A "GO" - Graphical Object (Sprite, Window, Plane, or Tilemap) is created
2. The Graphical Object is assigned a Viewport
3. The Viewport is disposed, but the sprite is not
4. The Graphical Object is claimed by GC (garbage disposal)*

* - Newly Discovered: attempting to dispose a sprite that has a disposed viewport
will occasionally also crash. (v 1.1)
Note that this particuar crash only seems to occur if screen draws have taken
place (any of the Graphics methods) between the time the viewport is disposed
and the sprite disposal is attempted.

Due to the way GC is implemented, you are unlikely to see an immediate effect
when the situation comes up. It could be several scene changes down the line
before the crash finally happens. To make matters worse, following the exact
same course of action will yield completely different results, making it seem
as though the crashes are random. In addition, there is yet another circumstance
which I have still been unable to pinpoint, but I suspect has something to do
with the order in which assets associated with the Graphical Object are claimed
by the GC, or the amount of screen rewdraws that have taken place,
that allows the GO to be cliamed without causing an exception and
thus making it even harder to find.

In essence: you could be suffering from an unstable game and not even know it.

So that is where this little script comes in. This does the following:

1. Creates a global variable backreference to every Graphical Object created.
This prevents them from being marked by the GC so long as the reference exists,
circumventing the final condition to cause this version of the crash.

2. Removes reference to the Graphical Object once it has been disposed.
This reallows the object to be marked by GC for disposal (once all other
references are removed). Since the GO is disposed, condition 3 is no longer met
and the object is deemed 'safe'.

3. Report on potential issues to the user.
This allows the user (given limited scripting knowledge) to identify potential
errors and fix them outright.

4. Prevents further Game.exe crashes caused by this specific issue.
Includes a 'lazy' fix that cleans up offending Graphical Objects when the scene
changes.*

* v 1.1 'Lazy' fix has been superceeded to prevent crashes caused by disposal of
these errant sprites. Lazy fix only works if debug criticial disposal has
been disabled.

Version History:

v 1.1
Discovered a new condition for a Game.exe crash. Updated script to trap and log
this error also.

v 1.01-1.05
Minor bugfixes, improved logging, added consideration for Plane objects viewport method error

v 1.0
Initial Release

Features
- Identifies and reports a prevalent, and generally very easy to fix, cause of Game.exe crashes.
- Creates a global reference to every graphical object created until it is disposed to prevent the error from causing this specific Game.exe crash while it is running
 
Script
http://pastebin.com/raw.php?i=rW9qkbxT

How to Use
Install on its own script page in the materials section of the script editor above main and below default scripts. If using a script that creates sprites at startup (eg. Woratana Simple Mouse System), this script must come after it on the list.


FAQ
Q: Game.exe crashes for me constantly and this didn't help!
A: As explained, this only prevents Game.exe crashes caused by the specific set of circumstances outlined. Crashes caused by memory faults or other errors may still remain, but if there is an in-game reason for it (read: crashes happen after x set of actions are taken with a fair degree of consistency, or across several computers) feel free to leave a post here.

Q: I'm using a cracked version and..
A: Support will not be given for non-official versions. Using a cracked version is also against the forum rules, among other things, and will get you banned.

Q: I found another way to force a Game.exe crash in a seemingly stable game.
A: I'd love to hear about it. Drop a post with the details.

Credit and Thanks
- Mithran

Author's Notes
May be distributed with a link to these forums, original unedited script, and with credit. May be used in any project, so long as the credit in the script remains intact (individual credit in the project as a whole is not required).

Bug Reporting
If you encounter an error, please provide the complete error code as well as a short description on how to reproduce.

 

[Ronove]

Seriously guys: if any of you have a problem with RGSS2 crashes, this script will help amazingly.

 

[Kread-EX]

This is wonderful. I just tested it with my old Win XP computer (where VX Game.exe was crashing all the time) and it works.

 

[Lunarea]

Thank you so much for this, Mithran! I've had a couple friends who couldn't play my project due to .exe issues, and this script really helped!

 

[Maus Merryjest]

I've found one big issue with this script: If you're using Yanfly's Party System + Command Party, accessing the "Party" command on the battle menu will cause the game to hang up from 8 to 12 seconds or more. Then, the party menu will come up finally. After that, accessing the party menu during battle will take no time at all... but that initial delay is a killer.

 

[Mithran]

The most significant thing this script does resource wise is logging errors, so if you experience a delay that big it is likely that there is a problem with one or more of your scripts.  This can be disabled in options, but I would highly recommend looking into the problem instead and getting the scripts fixed.

The next most resource significant operation is the updating of the global list, (the function that prevents crashes garbage collection that will cause the crashes) which is relatively minor compared to the actual creation/destruction of each sprite it coincides with, so you shouldn't see any significant extra delay from this unless hundreds of sprites are being created/destroyed.  This function cannot be disabled in the script, as is the main function of the script, but if you are not logging any errors or getting any popups with logging on, this script will likely not save you any crashes and can safely be removed.

Either way, I'd like to investigate.  Please send me a test project so I can root out the problem.  

 

[Archeia]

Mithran, by any chance this still could happen in VXACE?


A few friends would get the exe errors (usually in Windows XP) and I can't pinpoint it out. But I was told it's usually in battle and on rare cases, in the map.

 

[Maus Merryjest]

I think I may have gleaned the problem, actually... see, over time (months) I forgot to clear out the log file. Eventually it became 3 megabytes of text, and i guess the game was lagging because it kept trying to write to such a large file. I cleared the .txt file and ran it again, and this time there was no issue whatsoever. It became 32kb, then on the next test, 72kb, and no pause. I guess the issue hits when the log file becomes too large... which means I should probably turn off the logging feature at release time.

 

[Mithran]

@Maus - I'd still like a peek at your project, at the very least your script file and a logfile after it has gone through at least one iteration.  If you are logging that many errors with non-critical logging off, it will be better to fix them rather than just going with the workaround my script does to prevent the crashing.

@Archeia - 

I managed to replicate the problem in VX with a simple loop.  Depending on what else I did in the loop (sound effects, transitions, etc), it would crash in as low as one iteration of not disposing the sprites before the viewport.  When removing some things from the loop, it sometimes took more iterations to crash, but it would always crash eventually.  When testing the same code in VXA, a crash did not occur.  So I am fairly certain it is not this specific error causing the crash, if it happens in VXA.

My VX viewport disposal crash exposer can be found here:

http://pastebin.com/23LNNhuS

With minimal tweaking, it runs in VXA (namely, change the sound effect file to cursor1 or something).  I pushed it to every limit I could think of that would give me reason to believe a similar error would cause the crash (300 iterations of not disposing the sprite PER frame, letting it run for a few minutes, then entering the game normally) and I haven't been able to force it.  So I am reasonably certain that this specific error has been fixed for Ace.

Now, that is not to say that there isn't an error tangentially associated, which shares one or more of the same conditions, just that I haven't found one.  If the errors are repeatable, over more than one machine, and use custom scripts, it is reasonable to at least explore the possibility that a scripting error is causing a game.exe crash.  Which, barring some specific cases (errant dll calls and corrupted files could do this in VX), it shouldn't, as that means it was missed by Ruby's error handler.  In other cases, it may be related to the user's machine or their install.  If you have some test cases that meet the criteria where I can replicate a game.exe in Ace crash, I'll be happy to take a look.

 

[Archeia]

I have this error reported a while back

Spoiler

And from what I know of, it happens most often in my game and someone occasionally got it from their game. To be honest I can't replicate the error at all so I was wondering if you have any idea of the cause?

 

[Mithran]

I have this error reported a while back

Spoiler

And from what I know of, it happens most often in my game and someone occasionally got it from their game. To be honest I can't replicate the error at all so I was wondering if you have any idea of the cause?

After a bit of research, I noticed that this error is fairly prevalent across many kinds of software.  The general consensus is that it is related to files with corrupted permissions.  However, this doesn't necessarily mean a file in the project has corrupted permissions, as it could be any of the modules actually required to run the program (or even some for windows in general) and can be indicative of a more serious underlying issue (eg., hard drive corruption).  It is not likely caused by any specific script.  If it happens with your game specifically across different machines, you may need to reset the permissions for your project file.  If its happening on one specific machine, I would start by ruling out the files associated with the project, then the VXA install and its dependencies.  If reinstalls don't help and it continues to crash across different projects, it may point to a system error. 

 

[Zyoshiro]

Your script really helped me. Thank you very much!

 

[Calliope-Shadow]

Awesome job on the script, but I'm brand new with RPG Maker and I need a little bit of help deciphering the error message I got. 

Running a playtest of my game (or the battle test) will cause the game to crash about 70% of the time. With the script in place, I end up with the message: "Unable to find file: Data/Scripts.rvdata". I made sure that the scripts.rvdata was in the folder and everything (it is) so based on my limited knowledge of computers and programming the only idea I have is that the scripts.rvdata is somehow unreadable, or the system is looking for it in the wrong place. Anyone have any ideas how I can go about troubleshooting this?

 

[Mithran]

This script is for RPG Maker VX. If you are attempting to use it in RPG Maker VX Ace, it will not work (but it should crash 100% of the time, not just 70%). If you are getting this error message in VX, please let me know. If you are having another problem with Game.exe crashes in VX Ace(eg. not a script error, either 'game.exe has encountered a problem and needs to close' or no error message and program closes), please PM me.


EDIT:


Confirmed he was having problems with VX Ace crashes due to DEP/permissions issues, which were solved by this thread:


http://forums.rpgmakerweb.com/index.php?/topic/10789-playtest-crashes-immediately-on-start/

 

[Kalithro]

For RPGMAKER VX ACE

I changed a line from """"load_data("Data/Scripts.rvdata").each_with_index {|s, i| ScriptNames = s[1] }""""" to

"""""load_data("Data/Scripts.rvdata2").each_with_index {|s, i| ScriptNames = s[1] }""""""

 

I simply added a 2 after "rvdata".

 

I then clicked on things rapidly and randomly over and over and over... no crahes.  Before I would have crashed many times.

 

 

[Mithran]

For RPGMAKER VX ACE


I changed a line from """"load_data("Data/Scripts.rvdata").each_with_index {|s, i| ScriptNames = s[1] }""""" to


"""""load_data("Data/Scripts.rvdata2").each_with_index {|s, i| ScriptNames = s[1] }""""""


 


I simply added a 2 after "rvdata".


 


I then clicked on things rapidly and randomly over and over and over... no crahes.  Before I would have crashed many times.

Again, this is a VX script built as a workaround for a VX issue. Having the script work in VX Ace is not the issue, the issue is that it won't do anything for VX Ace users because the problem that causes the crashes that this script stops has not once been shown to happen in VX Ace after testing multiple projects. If you are having issues with Game.exe crashes, eg "RGSS3 player has stopped working" or "Game.exe has encountered a problem and needs to close"(not script errors), please PM me and/or make a support thread. If you are not either having issues with Game.exe crashes or are not a scripter looking to debug your scripts from having non disposed graphics left in memory, you should not use this script.

 

[Kalithro]

Yes, I have something else going on.  Will make a new topic.

 

[gecebd]

Hi ! Thanks a lot for this script, I really hope to learn about scripts erros thanks to this report ;

Time: 2013-08-11 22:25:30 +0200Critical Object #<Sprite_Base:0x782aff8>In Scene NilClassCaller:: {0147}:87:in `update_hp_bar'{0147}:82:in `update'{0148}:87:in `update'{0049}:333:in `block in update_enemies'{0049}:333:in `each'{0049}:333:in `update_enemies'{0049}:311:in `update'{0049}:20:in `initialize'{0116}:146:in `new'{0116}:146:in `create_spriteset'{0116}:13:in `start'{0129}:346:in `start'{0099}:12:in `main'{0122}:203:in `main'{0006}:23:in `run'{0156}:7:in `block in <main>':1:in `block in rgss_main':1:in `loop':1:in `rgss_main'{0156}:7:in `<main>'ruby:in `eval'What's wrong with this script ? I really need it and canno't remove the script, hopefully there will be a solution, thanks !

 

[Mithran]

I'm seeing the log reference rgss_main, which is something ACE added. Once again, this is not an ACE script as the described issue doesn't happen in ACE. If you are getting random crashes in ACE, please make a support thread in the appropriate forum. If you are using ACE and not crashing, there is nothing 'wrong' with the script in question.


All the log tells you is the backtrace of the creation point of any graphical object that is not disposed when the scene switches. In this case, that object would be likely be somewhere in the update_hp_bar method in script 147, around line 87 (the number to name conversion does not appear to be working here due to ACE's differing format). So starting in that method, you'd see if any new Sprite_Base objects are being created, specifically on this line, and note the name of the variable it is stored in somewhere. From there, you need to make sure the objects are disposed at a logical point before the scene switches, which will vary depending on the individual case. Again, in this case, the object seems to be inside a spriteset, so whichever spriteset created it should also contain the disposal method. This is just part of basic coding practice when dealing with sprites stored within Scene specific objects, this script just helps to identify those that slip through the cracks as this can cause VX (not ACE) to crash without warning or any indication of where the actual error is. In ACE, it is still good practice to clean up your graphical objects, but the issue this script is meant to debug has never shown to cause a crash in ACE, nor any other noticeable adverse effect, and it is not recommended you use this debug script with ACE.

 

[gecebd]

Thanks a lot, but then where can I submit my report if this is not the good topic ? Nevertheless thanks a lot fir your answer !