Hidden Game.exe Crash Debugger - Graphical Object Global Reference ACE

[Archeia]

Hello Mithran, I'm encountering an RGSS3 Player Crash whenever I win a battle and return to the map. GOBJ isn't detecting anything so we're stumped. I tried enabling GOBJ_DEBUG_CRITICAL_DISPOSAL but it only gives me an error the moment I start new game etc.. GOBJ_Lazy doesn't do anything either. I enabled all notifications and still get nothing. Help? :<

It works perfectly fine before ;-;

 

[Mithran]

I just noticed the script doesn't log in certain circumstances when the SceneManager returns to a previous scene, so I removed that bit of code so it will always performs the check when switching scenes (changed at original link). This was also preventing the "Lazy" check in those circumstances.


The startup 'disposed sprite' crash is happening because the sprite is being disposed more than once, and metadata like viewport is not available if the object is already disposed. When a 'dispose' is triggered, that bit of code checks to see if the viewport is already disposed and if not, disposes it as well. However, it can't even perform the test to see if the viewport is disposed or not when the sprite itself is already disposed (the Sprite itself is not actually using the original dispose method to free the object until the end of that method, which is how I know it is being run more than once.) Using dispose on a disposed sprite normally is just ignored (though really you should not be attempting a dispose more than once, I don't think that is causing your Game.exe crash, but it is usually indicative that you need better control of your sprites). I updated the script to ignore duplicate disposes to mirror default behavior, though I may at a later time update to log those too.


You can try it again and see if it logs. Is the map screen actually showing up or is it crashing during the transition?

 

[Mithran]

Thanks for the test case, Archeia.


Update: 1.21

• error logger will now check every scene switch instead of only triggering on new scene instances
• GOBJ_DEBUG_CRITICAL_DISPOSAL setting is now on by default. This error has been shown to cause Game.exe crashes with 100% certainty in a test case before the scene can even switch, so this test is crucial
• Added a setting in the script to warn on repeat disposals. While repeat disposes are normally just ignored by the base scripts, good practice would be to dispose these objects once and only once. Notification is on by default, and logging is off.
• Repeated disposal of sprites will otherwise be ignored by the script
• GOBJ_LAZY is reworked to ONLY dispose sprites that will not trigger the crash (ie., those marked as memory leaks), rather than dealing with the critical objects. Disposing sprites with disposed viewports, even before a scene switch, has now been shown that it can trigger this crash

Link is in original post.

 

[daniacea]

Mithran,

Thanks for replying to my post over in the VX version. Yes I am using Ace.  I tried the suggestions you gave. 

I turned off NOTIFY_REPEAT_DISPOSE and GOBJ_LOG_REPEAT_DISPOSE to false. I am getting no gobj logged errors.

I will describe the error some more. It is a windows exception error which occurs during scene changes such as opening the menu, entering or exiting a

battle or opening a shop screen. I am using Yanfly's battle system and core scripts. I am using a bunch of other scripts as well. 

Just so I know what to look for, do you know of any other cause of this type of crash? Can it just be a problem with the script or is it more likely a corrupted file within rpgmaker?

The windows error in event viewer always prints the same error;



Event Type: ErrorEvent Source: Application Error

Event Category: None

Event ID: 1000

Date: 9/19/2014

Time: 8:20:01 PM

User: N/A

Computer: A

Description:

Faulting application game.exe, version 3.0.0.1, faulting module rgss301.dll, version 3.0.1.1, fault address 0x0010ac8e.

 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Data:

0000: 41 70 70 6c 69 63 61 74   Applicat

0008: 69 6f 6e 20 46 61 69 6c   ion Fail

0010: 75 72 65 20 20 67 61 6d   ure  gam

0018: 65 2e 65 78 65 20 33 2e   e.exe 3.

0020: 30 2e 30 2e 31 20 69 6e   0.0.1 in

0028: 20 72 67 73 73 33 30 31    rgss301

0030: 2e 64 6c 6c 20 33 2e 30   .dll 3.0

0038: 2e 31 2e 31 20 61 74 20   .1.1 at 

0040: 6f 66 66 73 65 74 20 30   offset 0

0048: 30 31 30 61 63 38 65 0d   010ac8e.

0050: 0a  

 

I found a fix in this forum thread for yanfly's battle system and installed it but the crashes remain. They don't occur everytime and usually not right away it takes about 5-10 minutes of gameplay for them to happen and it seems they happen in one particular area more than others.

 

I have another error logger which catches errors with scripts and it is showing nothing on these particular crashes.

 

Here is a complete list of all the scripts I am using, in order that I have them installed;

Ace Core Engine

Ace Battle Engine

Yanfly Enemy HP Bars

Yanfly Engine Ace - Battle Engine Add-On: Elemental Popups v1.00

Yanfly Engine Ace - Command Autobattle v1.01

Yanfly Engine Ace - Battle Command List v1.09b

The Yanfly battle engine fix from this thread

Note Field Hash by Killo Zapit

Dungeon Creation 6 KZ Edit ( based on Saba Kan Random Dungeon Generator)

DMO - RANDOM NAME SCRIPT

Yanfly System Options

Yanfly Engine Ace - Ace Menu Engine v1.07

Victor Engine - Basic Module

Victor Engine - Diagonal Movement

Large Choices by: Tsukihime 

Yanfly Engine Ace - Adjust Limits v1.00

Dual wield / two-handed fix by Trihan

Graphical Object Global Reference

Exception Logger [VX Ace] - v1.0.1  by Krosk

 

So I just need an idea of where to look for what could cause this type of error. Thanks again. 

 

[Mithran]

The problem you are describing fits the bill for being caused by the undisposed sprite memory access error this script is meant to detect. However, this script with GOBJ_DEBUG_CRITICAL_DISPOSAL set to true should block all instances of this specific thing happening. Since my script aliases "new" for all affected objects to log them, every single one created should be logged. And critical disposal warning kicks in whenever you try to dispose the sprites if their Viewport is already disposed, which is the basis for the error. I'm not thinking of another way to sneak around detection since I added this, but there could be something I'm not thinking of.

Corrupted files are almost always an 100% thing, eg., whenever attempting to load a corrupted resource, it will crash 100% of the time. The scripts themselves might conditionally load said resource, causing the problem to be intermittent, but in my experience, if the image is corrupted/malformatted/cannot be read by RM, you will be able to reproduce it 100%. I have mainly seen this happen when you have an image file and another file with the same base name and different extension. In these cases, the game is trying to load the wrong image file. If you get the crash when the game is compress but it stops with normal files, this is also another indicator, because the extension priority changes when the game is compressed. Image or sound files could also be straight up corrupted. The way I normally detect these is by temporarily adding a "p filename" line in Cache.load_bitmap, playtest with console open, and see if the same file continually pops up on the console right at the time of crash. If so, this file is probably corrupted. Music files I have not personally dealt with them being corrupted, but it should be fairly obvious if the crash occurs right before a specific sound is meant to be heard. Setting the font name to an bitmap font will also crash the game, but again, it will be fairly obvious since it would be in the same place every time. If you have corrupted project files, you should be getting Ruby errors instead of game.exe crashes.

Other much less common Game.exe crash errors related to the project I have seen are the GDI object limit being reached (having 10000+ bitmaps in memory at the same time) which would commonly make the window unable to even correctly form the crash dialog, as it is also a GDI object. The GDI object error can occur with the base scripts from the earliest English release of Ace wherein erased pictures would rapidly create and dispose blank bitmaps, occasionally faster than the system could catch up. However, if you have the following in your Sprite_Picture script, then you have the fixed version and should be fine.

def update_bitmap if @picture.name.empty? self.bitmap = nil else self.bitmap = Cache.picture(@picture.name) end endI've not seen this bug in any known custom script, but it could be caused by a similar issue. Other symptoms are the game having a jerky or stuttered playback. This crash is also most likely to occur when leaving a scene running instead of during a switch.Another is the hardcap memory limit of ~1.8gb being breached. In this case, if you examine the program in task manager before you exit it you should see the memory used is at or above 1.8gb. This can be caused due to a script loading the same bitmap over and over without caching it and also maintaining a variable with all these bitmap copies. Again, this one is pretty rare because it is pretty hard to do unless you are trying to do it you either need absurdly big images, or have a ton of them loaded at a time (roughly 2000 images of 640 x 480 each). The base scripts will dispose parallaxes, battlers and animations even when cached, so you aren't likely to hit more than around 300mb. If you are getting this error, it is probably a script that uses "Bitmap.new" a whole bunch. Or Bitmap.new with really big numbers.

The crash can be caused by something attempting to load outside of normal RGSS3 library files (using Win32API.new, DL.dlopen) followed by an improper call to the library, but I don't see anything suspect from that script list. You can search those two things, you probably wont find anything that uses them for those scripts.

Finally, it might just be specific to your computer in an as-yet unexplained issue. You can usually rule this one out if anybody else crashes when using the same project file. From this I can only give third hand information from reports I have heard, whereas all the above issues I have experienced or tested firsthand. I have heard very isolated reports that Windows DEP can sometimes mess with the RGSS3 player. I remember a couple reports of the steam client causing this so it may be worth trying to close Steam and running RM. Hardware or system software issues that affect RM but nothing else you use is also a possibility albeit very very remote. And obviously this should go without saying, but if this problem is occurring with a hacked version of RM, there is nothing I can or will do.

A few other questions:

Which version of Windows are you using? Have you ever Game.exe crashed on another project? On a brand new project with no custom scripts installed?

Does the game crash with my script installed? If you can get it to crash with this script installed, then whatever is crashing it wont be logged because logged critical objects are kept in memory (ie., quarantined) to prevent the crash. You'd notice slowdown after a while, and the game would be downright unplayable eventually, but it would take a long time and with a lot of errors logged. I remember one of Yanfly's scripts at one point (I think it was a VX script, not this one) used some kind of popup system that would spontaneously create and dispose popup sprites and bitmaps based on when they were needed. The code for disposal was self contained within the sprite itself, so it would sort of "self destruct" when no longer needed. However, it was possible to end the battle and abruptly skip the battle end text while the popup still existed, causing it to never be disposed. In this instance, the only time it would create an instability was quickly skipping through the battle end text while popups were on screen, otherwise, you won't log anything. You also wouldn't crash, though, which is why I ask. If you aren't crashing and aren't logging anything, you may just be not be triggering whatever is actually causing it. Also, try to keep it in your head which scenes you have visited since startup before the crash occurred. For example, if it occurs without ever entering battle, then the battle scripts are probably not the issue. But, it can still crash after a menu transition even if the object causing the error was created in battle. Sometimes, it seems like you can do a specific set of things and get it to crash, but if it is caused by a sprite, what matters is finding the sprite causing the actual problem. If you know where you don't need to go for it to crash, it narrows down where that sprite can be.

If you PM me with a project link, I will try to take a look at it this weekend.

 

[daniacea]

Thanks MIthran! For some reason I didn't get a email showing you had replied so I just saw your reply today.

I have turned GOBJ_DEBUG_CRITICAL_DISPOSAL on and it is now logging some objects in the minimap script. The game did not crash once I had this option on. I am noticing some screen jerkiness when walking around the map in areas with a lot going on.

I removed another debug script I had in 'Main' that traced errors for output in the console.

The minimap uses colored pixels as sprites and the color can be modified in the script. 

I am using Windows XP. I have tested other vx ace games on this system with no crashes. 

I checked the Sprite_Picture script and it matches the one you posted.

I checked all the scripts and none use Win32API.new or DL.dlopen.

I checked the memory when running and it is not near the limit. 

In the gobj log I am also seeing a reference to Ace Core Engine line 929:in `post_transfer'

I am PMing you with a link to the project and a copy of the gobj.txt file. 

 

[Mithran]

@daniacea

For the minimap script, install this under it.

# under dungeon minimap scriptclass Spriteset_Map def dispose @mini_map.dispose if @mini_map saba_minimap_dispose endendBasically, the only thing I can see that this script did "wrong" was having the viewport dispose before the sprites. Even though it was disposed right before the sprites, it was still enough to trigger a crash. So this is another confirmation that all sprites associated with a viewport must be disposed before the viewport is or you risk a crash.The base savefile script showing up is a bit more troubling. Sure enough, the base script has the same error that has now been proven to cause Game.exe crashes (viewport is disposed, THEN sprites), but I've not heard a single crash reported from this issue myself. It could be because of other factors that have yet to be determined (ie., in both test cases where the viewport disposed, then sprite disposed triggered a crash, the viewport dispose was conducted at a different local scope, which is contributory to how GC works). It could just be that it hasn't affected anyone aware enough to cite it as a possible cause, though, only my latest version of the debugger had on GOBJ_DEBUG_CRITICAL_DISPOSAL on by default. Either way, to be safe, you can also use this at the top of materials:

class Scene_File def terminate super # basically just making the viewport dispose last here instead of first @savefile_windows.each {|window| window.dispose } @savefile_viewport.dispose endendI'm just swapping the dispose order there to be windows then viewport instead of viewport then windows.You can delete the current log file and poke around some more and see if anything else comes up. If not, remove or comment out my script and you should hopefully be crash free.

 

[daniacea]

It looks like that worked! I have added both of the fixes and am showing no more objects in the gobj log and no crashes. I removed your script and also no crashes. 

I will share the fix over on the pages for the scripts which use this dungeon minimap in case anyone else has this same problem.

Great job Mithran and if there is anyway I can return the favor let me know. I will definitely add you to the game credits for this game.

 

[BoluBolu]

Oh there's a good topic here how come I just notice this now -__- a
Btw, I'm sorry if this is not right to ask here, but because this topic discussing about Gobj, I want to ask something, what is really happened if a viewport contains object(say window for example) is disposed first rather than the window itself? But then the window immediately disposed after that. I never do this though,  I actually found that in the Scene_File default RGSS3, The viewport for window savefiles is disposed first rather than the window itself. Is this not a problem in making the memory leak or anything else ? Thank you very much

EDIT : Oh you actually have posted this above< sorry just notice it now..

class Scene_File def terminate super # basically just making the viewport dispose last here instead of first @savefile_windows.each {|window| window.dispose } @savefile_viewport.dispose endend

Yeah2, like that what happensif viewport disposed first rather than object(window for this case) ?
Thanks Mithran

 

[Mithran]

Oh there's a good topic here how come I just notice this now -__- a


Btw, I'm sorry if this is not right to ask here, but because this topic discussing about Gobj, I want to ask something, what is really happened if a viewport contains object(say window for example) is disposed first rather than the window itself? But then the window immediately disposed after that. I never do this though,  I actually found that in the Scene_File default RGSS3, The viewport for window savefiles is disposed first rather than the window itself. Is this not a problem in making the memory leak or anything else ? Thank you very much


EDIT : Oh you actually have posted this above< sorry just notice it now..


Yeah2, like that what happens if viewport disposed first rather than object(window for this case) ?


Thanks Mithran

This the oddity of the bunch, actually. It has been proven through other test cases that disposing in this order but there have been no confirmed cases associated with the basic Scene_File script specifically. The only difference between the this and the test cases is that the test cases both used aliases of their respective methods to dispose their viewports, which put the disposal of the viewport at a different local scope. Since the termination of a local scope is a trigger for Ruby GC, and GC directly relates to why this crash happens, this may be the reason why performing both disposes in the same local scope has never been shown to trigger a crash. Again, this is judging by the fact where the savefile windows have not ever been found to be the cause of any crashes, and as a part of the base scripts, and the prevalence of crashes if there is an actual problem. There is no real way to prove that it will never cause a crash, I can only say that it is unlikely based on these indicators.


Basically, if you dispose the viewport before the window in the same local scope, you *should* be safe. If not, always always always make sure the windows (or sprites, whatever) are disposed the viewport. And if you have the choice, windows before viewport every time, even in the same local scope, just to be sure.

 

[BoluBolu]

Thank you very much for taking your time write explanation I appreciate it

 

[Nanaki_Fan]

Hello!

Little bit of necro posting here but I need help. I am using Venka's Bestiary logbook and I am getting the crash as outlined in this.

I have posted my error here in Venka's thread.

I am hoping someone can help fix my random game crashes :/

Here is my GOBJ report:

Spoiler

-----
Time: 2015-05-28 13:33:27 +0100
CRITICAL OBJECT #<Sprite:0x6b177e4>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:29 +0100
CRITICAL OBJECT #<Sprite:0x6b17410>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:31 +0100
CRITICAL OBJECT #<Sprite:0x6b16de4>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:32 +0100
CRITICAL OBJECT #<Sprite:0x6b16a88>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:42 +0100
CRITICAL OBJECT #<Sprite:0x6af94b0>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:43 +0100
CRITICAL OBJECT #<Sprite:0x6b175b4>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:44 +0100
CRITICAL OBJECT #<Sprite:0x6b16b28>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:46 +0100
CRITICAL OBJECT #<Sprite:0x6b17e10>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:47 +0100
CRITICAL OBJECT #<Sprite:0x6b181f8>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:33:51 +0100
CRITICAL OBJECT #<Sprite:0x6b16754>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:34:06 +0100
CRITICAL OBJECT #<Sprite:0x6b163a8>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:34:09 +0100
CRITICAL OBJECT #<Sprite:0x6b163f8>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:34:54 +0100
CRITICAL OBJECT #<Sprite:0x6b15f84>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 13:35:02 +0100
CRITICAL OBJECT #<Sprite:0x6aec558>
In Scene Scene_Bestiary
Creation Stack::
Script 0157 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0157 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0157 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'

EDIT:

Here is a new error log. This is what I get after a  batttle:

Spoiler

-----
Time: 2015-05-28 20:58:24 +0100
Memory Leak #<Sprite:0x6b54dd8>
In Scene Scene_Battle
Creation Stack::
Script 0161 -- Beastairy, Line: 1691:in `create_info_instructions'
Script 0161 -- Beastairy, Line: 1657:in `create_all_windows'
Script 0117 -- Scene_Battle, Line: 14:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 20:58:26 +0100
CRITICAL OBJECT #<Sprite_Object:0x6b077e0>
In Scene Scene_Battle
Creation Stack::
Script 0140 -- yami battle, Line: 3083:in `create_icon'
Script 0140 -- yami battle, Line: 899:in `block in action_create_icon'
Script 0140 -- yami battle, Line: 896:in `each'
Script 0140 -- yami battle, Line: 896:in `action_create_icon'
Script 0140 -- yami battle, Line: 526:in `block in perform_actions_list'
Script 0140 -- yami battle, Line: 508:in `each'
Script 0140 -- yami battle, Line: 508:in `perform_actions_list'
Script 0140 -- yami battle, Line: 852:in `action_autosymphony'
Script 0140 -- yami battle, Line: 523:in `block in perform_actions_list'
Script 0140 -- yami battle, Line: 508:in `each'
Script 0140 -- yami battle, Line: 508:in `perform_actions_list'
Script 0140 -- yami battle, Line: 3280:in `block in use_item'
Script 0140 -- yami battle, Line: 3278:in `each'
Script 0140 -- yami battle, Line: 3278:in `use_item'
Script 0133 -- Yanfly battle engine, Line: 2990:in `execute_action'
Script 0140 -- yami battle, Line: 3337:in `execute_action'
Script 0117 -- Scene_Battle, Line: 550:in `process_action'
Script 0117 -- Scene_Battle, Line: 48:in `update'
Script 0161 -- Beastairy, Line: 1743:in `update'
Script 0100 -- Scene_Base, Line: 14:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 20:58:29 +0100
CRITICAL OBJECT #<Sprite_Popup:0x64e8544>
In Scene Scene_Battle
Creation Stack::
Script 0133 -- Yanfly battle engine, Line: 881:in `create_new_popup'
Script 0133 -- Yanfly battle engine, Line: 865:in `setup_popups'
Script 0133 -- Yanfly battle engine, Line: 854:in `setup_new_effect'
Script 0045 -- Sprite_Battler, Line: 42:in `update'
Script 0140 -- yami battle, Line: 1939:in `update'
Script 0155 -- Yanfly Enemy HP bars, Line: 225:in `update'
Script 0140 -- yami battle, Line: 2162:in `block in update_actors'
Script 0140 -- yami battle, Line: 2150:in `each'
Script 0140 -- yami battle, Line: 2150:in `each_with_index'
Script 0140 -- yami battle, Line: 2150:in `update_actors'
Script 0050 -- Spriteset_Battle, Line: 312:in `update'
Script 0117 -- Scene_Battle, Line: 59:in `update_basic'
Script 0133 -- Yanfly battle engine, Line: 2576:in `update_basic'
Script 0151 -- Pause, Line: 86:in `update_basic'
Script 0117 -- Scene_Battle, Line: 67:in `update_for_wait'
Script 0117 -- Scene_Battle, Line: 111:in `wait_for_effect'
Script 0086 -- Window_BattleLog, Line: 189:in `call'
Script 0086 -- Window_BattleLog, Line: 189:in `wait_for_effect'
Script 0140 -- yami battle, Line: 3451:in `perform_collapse_check'
Script 0133 -- Yanfly battle engine, Line: 3008:in `apply_item_effects'
Script 0161 -- Beastairy, Line: 1771:in `apply_item_effects'
Script 0117 -- Scene_Battle, Line: 597:in `invoke_item'
Script 0133 -- Yanfly battle engine, Line: 3109:in `invoke_item'
Script 0140 -- yami battle, Line: 3314:in `invoke_item'
Script 0140 -- yami battle, Line: 839:in `block (2 levels) in action_skill_effect'
Script 0140 -- yami battle, Line: 839:in `times'
Script 0140 -- yami battle, Line: 839:in `block in action_skill_effect'
Script 0140 -- yami battle, Line: 836:in `each'
Script 0140 -- yami battle, Line: 836:in `action_skill_effect'
Script 0140 -- yami battle, Line: 520:in `block in perform_actions_list'
Script 0140 -- yami battle, Line: 508:in `each'
Script 0140 -- yami battle, Line: 508:in `perform_actions_list'
Script 0140 -- yami battle, Line: 852:in `action_autosymphony'
Script 0140 -- yami battle, Line: 523:in `block in perform_actions_list'
Script 0140 -- yami battle, Line: 508:in `each'
Script 0140 -- yami battle, Line: 508:in `perform_actions_list'
Script 0140 -- yami battle, Line: 3280:in `block in use_item'
Script 0140 -- yami battle, Line: 3278:in `each'
Script 0140 -- yami battle, Line: 3278:in `use_item'
Script 0133 -- Yanfly battle engine, Line: 2990:in `execute_action'
Script 0140 -- yami battle, Line: 3337:in `execute_action'
Script 0117 -- Scene_Battle, Line: 550:in `process_action'
Script 0117 -- Scene_Battle, Line: 48:in `update'
Script 0161 -- Beastairy, Line: 1743:in `update'
Script 0100 -- Scene_Base, Line: 14:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 20:58:31 +0100
CRITICAL OBJECT #<Sprite_Object:0x6ac1b8c>
In Scene Scene_Battle
Creation Stack::
Script 0140 -- yami battle, Line: 3083:in `create_icon'
Script 0140 -- yami battle, Line: 899:in `block in action_create_icon'
Script 0140 -- yami battle, Line: 896:in `each'
Script 0140 -- yami battle, Line: 896:in `action_create_icon'
Script 0140 -- yami battle, Line: 526:in `block in perform_actions_list'
Script 0140 -- yami battle, Line: 508:in `each'
Script 0140 -- yami battle, Line: 508:in `perform_actions_list'
Script 0140 -- yami battle, Line: 852:in `action_autosymphony'
Script 0140 -- yami battle, Line: 523:in `block in perform_actions_list'
Script 0140 -- yami battle, Line: 508:in `each'
Script 0140 -- yami battle, Line: 508:in `perform_actions_list'
Script 0140 -- yami battle, Line: 3280:in `block in use_item'
Script 0140 -- yami battle, Line: 3278:in `each'
Script 0140 -- yami battle, Line: 3278:in `use_item'
Script 0133 -- Yanfly battle engine, Line: 2990:in `execute_action'
Script 0140 -- yami battle, Line: 3337:in `execute_action'
Script 0117 -- Scene_Battle, Line: 550:in `process_action'
Script 0117 -- Scene_Battle, Line: 48:in `update'
Script 0161 -- Beastairy, Line: 1743:in `update'
Script 0100 -- Scene_Base, Line: 14:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 20:59:23 +0100
CRITICAL OBJECT #<Sprite:0x6b63b94>
In Scene Scene_Bestiary
Creation Stack::
Script 0161 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0161 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0161 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'
-----
Time: 2015-05-28 20:59:28 +0100
CRITICAL OBJECT #<Sprite:0x6b6604c>
In Scene Scene_Bestiary
Creation Stack::
Script 0161 -- Beastairy, Line: 1926:in `create_enemy_image'
Script 0161 -- Beastairy, Line: 1850:in `create_all_windows'
Script 0161 -- Beastairy, Line: 1803:in `start'
Script 0100 -- Scene_Base, Line: 12:in `main'
Script 0126 -- Graphic object debug, Line: 246:in `main'
Script 0006 -- SceneManager, Line: 23:in `run'
Script 0164 -- Main, Line: 7:in `block in <main>'
:1:in `block in rgss_main'
:1:in `loop'
:1:in `rgss_main'
Script 0164 -- Main, Line: 7:in `<main>'
ruby:in `eval'

It would appear Venka's, Yami, yanfly and some others are all reporting errors?
 

 

[Mithran]

@Nanaki_Fan - have you checked the rest of this thread yet? The Yami and Yanfly errors both sound vaguely familiar, it may be something there is already an existing fix for. The bestiary error is probably being caused because the sprite is being disposed after the viewport and in a different scope, specifically in this method in Scene_Bestiary toward the end of the script:

def terminate super fadeout_all(60) @map_bgm.replay dispose_enemy_image end'super' includes a path to dispose_main_viewport, which disposes '@viewport'. dispose_enemy_image disposes a sprite that uses this viewport. Move the line up so the image disposes before the viewport and you should be good on this one. For example:

  def terminate    dispose_enemy_image    super    fadeout_all(60)    @map_bgm.replay  end

The same thing is likely happening with the "@info_instructions" sprite in Scene_Battle:Edit: Nevermind, this one doesn't have an associated viewport.

Unfortunately, I just don't have time right now to do full traces and go digging for the other ones right now as I have a hard deadline to meet. Read all the posts in this thread, and the respective script sources, though, these sound really familiar. If they aren't in the threads, please give me links to demo(s) so I can quickly find out which sprite is not being disposed, and from there it is usually the matter of just fixing a missing or misplaced line. If not, I may not be able to help you for a while.

 

[AltairPL]

@Mithran

I've started getting crashes after porting my scripts from XP to VX Ace and had no idea what whas the cause - I used auto disposal of Sprites and Planes along with Viewport extensively as a feature (to prevent unnecessary iterations, etc.).

I didn't really need your script , but your explanation of the problem was just spot-on and helped me fix my problem, so I just wanted to thank you very much for it .

 

[Nanaki_Fan]

@Nanaki_Fan - have you checked the rest of this thread yet? The Yami and Yanfly errors both sound vaguely familiar, it may be something there is already an existing fix for. The bestiary error is probably being caused because the sprite is being disposed after the viewport and in a different scope, specifically in this method in Scene_Bestiary toward the end of the script:

def terminate super fadeout_all(60) @map_bgm.replay dispose_enemy_image end'super' includes a path to dispose_main_viewport, which disposes '@viewport'. dispose_enemy_image disposes a sprite that uses this viewport. Move the line up so the image disposes before the viewport and you should be good on this one. For example:

  def terminate    dispose_enemy_image    super    fadeout_all(60)    @map_bgm.replay  end

I shall take a look and go through the thread.

If I don't have any look I will drop you a PM

 

[RydiaMist]

I am having something of an odd problem. After playing my game for an extended period, things very slowly start to slow down for some users. However, memory usage remains stable. Using your script, it spotted 2 memory leaks and a few critical objects. I tracked them down as best I could. One was related to a help window in Modern Algebra's Choice Options script. I don't even use that feature, so I just stopped that window from even being created, which solved that. It's the others that are the problem though, because as far as I can tell, they are being disposed, yet your script says they aren't.

I was hesitant to post because my game uses a ton of custom scripts, edited in various ways... but at this point I am really wanting to track down this slowdown that some players are having. I am attaching my log file, I'd really appreciate it if you could have a look at it.

http://www.lakupo.com/rydiamist/gobj.txt

My issue is, it seems as if all of those objects are being disposed in the scripts... so I am wondering why I am being told they are not. They seem to be all related to Tankentai, and the memory leak is related to an extra cursor used in the battle system. If you need a link to my game (warning, it's pretty huge because it's a released game), it's here:

http://1drv.ms/1Qj1gWn

Thanks for any help you can provide, I've been scratching my head over this. The game never seems to crash, and players have been able to play through the entire thing in long sessions with no issue, but I'd really like to fix the slowdown some are having if possible. :/

EDIT: That link does not have the ATS Choices help window fixed. I already took care of that one. That link also has your script configured to catch objects as a precaution.

EDIT2: Oh, I actually just looked a couple of posts above, and that gave me something to go off of to maybe try and look a little more. Also no problem if you're busy and can't give detailed help.

EDIT3: It seems like fixing that help window has fixed the problem for the most part. I am still curious, though.

 

[Mithran]

@RydiaMist - Modern_algebra help window in the choice options script one is definitely one that has come up before. I remember specifically contacting him about it and it should be fixed in the latest version of this script, and I thought I also had a patch here. Looks like you already have that taken care of, though.


Sometimes the actual problem is a bit more complicated than a missing dispose line, but rather the design as a whole. I remember fixing an error with Tankentai (VX version) similar to what you have posted here where actor sprites were being not disposed. The actual issue in that case was that certain sprites were being created on the fly during the scene, and so if they were created more than once, they were being stored to the same variable. End result was that the first time the sprite was created, it would be put into the variable. The second time the sprite was created, it would be stored in the same variable and the first sprite would be orphaned. When the scene ends, the second sprite disposes and the viewport will dispose, but the first sprite is still in memory (which is a critical memory leak, since the viewport has already been disposed). To avoid this, the method that creates these sprites needs to check if the variables already contain sprites before creating new ones, or it will need to clean up the sprites that are in those variables by disposing them first.


I vaguely remember fixing the shadow issue in tankentai, too, but I thought that was just a straightforward missing or misplaced dispose. Unfortunately, I can't find the patches I did for the VX version, so I'm just going off memory here.


You won't always get a crash when leaving a critical memory leak, but leaving a bunch of sprites in memory will bog down gameplay, as the cost to perform any action on the metadata of the sprite (ie., disposing it, moving it, updating it in general) increases for every other sprite (or window, plane, tilemap, etc.) that exists in memory, whether or not it is currently being updated, and the cost of Graphics.update increases with the number of sprites in memory as well. The game.exe crash can range from very very rare to 100% reproducible due to the way Ruby handles garbage collection (nearly entirely encapsulated and the point of GC is actually the moment that the crash will occur). It can be so finicky that changing a single line in the same method that disposes the sprite or viewport not even related to the actual problem can make it appear to stop the crashing because it changes garbage collection, but the underlying problem will still exist. When ACE was brand new, in fact, I performed the same series of actions that can cause a guaranteed crash in VX after one iteration, and ACE did not crash after thousands of iterations and concluded that this specific crash bug had been fixed from VX to ACE. It wasn't until several reports of anecdotal evidence and MUCH later a project where I was finally able to reproduce it, verify that this is still a problem in ACE, that I finally ported this script over from VX.


I don't have time for full playtesting and tracing right now (I'm under the gun with some deadlines coming up next month), but I will take a look at the linked project later and see if I can remember anything else. (later tonight, once it has finished downloading)

 

[Mithran]

@RydiaMist - If I'm reading the other scripts correctly, DoubleX States aliases create_actors in Spriteset_Battle then overwrites the @actor_sprites array with another array of newly created sprites. In addition, two of your other scripts overwrite this method (VE: Actors Battlers and Sideview) with only the latter one being in effect. This will unfortunately not be able to be fixed without an actual analysis of these scripts, which I just dont have time to do right now.

Most of the other errors come down to this method on line 4909 of Sideview:

  alias dispose_sprite_battler_n03 dispose  def dispose    dispose_sprite_battler_n03    @shadow.dispose if @shadow != nil    @balloon.dispose if @balloon != nil    @cursor.dispose    for mirage in @mirages do mirage.dispose end if @mirages != nil    for anime in @next_anime do anime.dispose end if @next_anime  end

The dispose_sprite_battler_n03 alias includes the code to dispose the viewport. All the associated sprites need to be disposed beforehand, like so:

  alias dispose_sprite_battler_n03 dispose  def dispose    @shadow.dispose if @shadow != nil    @balloon.dispose if @balloon != nil    @cursor.dispose    for mirage in @mirages do mirage.dispose end if @mirages != nil    for anime in @next_anime do anime.dispose end if @next_anime    dispose_sprite_battler_n03  end

There may be others, that is just what I noticed on review based on prior experience.

 

[RydiaMist]

Edit: You replied as I was writing this! Thank you so much, let me take a look at your post and I'll edit this one further with results!

As for the array, I think I might be able to at least band-aid that. I am going to take a look at the scripts now. I am a mediocre scripter and can usually solve problems as long as I know where to look. Thanks a lot for the pointers, I am going to see what I can do about that array.

Edit2: The problem seems to be fixed! I realized that the Tankentai method and the DoubleX method were essentially doing the same thing, so a quick edit plus your revised dispose method was all it took. Nothing at all is coming up in the console or in gobj.txt now. Thanks so much for the pointers and taking the time to look, I imagine it's probably safe to turn off gobj_lazy and gobj_critical now!

 

[Mithran]

The script logs the most things with more logging options on, most those options are just there so that the user can narrow the focus to one specific set of problems at a time (I've seen logs with literally dozens of errors reported from a single playtesting session - usually the same one over and over, but having only critical to focus on makes it a bit easier to start). If the script isnt logging anything with all the logging options on, you can safely remove it. The script itself intentionally leaks memory to prevents crashes by keeping all created sprites in a global array until they are disposed (thus taking Garbage Collection out of the equation for these sprites). The "lazy" option disposes orphaned sprites that don't have a viewport when the scene switches, but any critical sprites have to be kept in memory indefinitely to prevent the potential crash. Since you have everything fixed, the only benefit of keeping this script installed is to catch any future errors that may crop up in other areas of the game, which would best be done with at least GOBJ_LOG_NON_CRITICAL and GOBJ_DEBUG_FILE on (the "notify" options just print to console during playtesting, and only if you have it enabled, more for immediate feedback). Lazy option should be turned off, though, it is always better to just fix it at the source.