Fatal Error (memory could not be read)

[apostrophe841]

Hi there, I am working on a map in the world editor and sometimes get an error like this when I try to play the map:

"This application has encountered a critical error. FATAL ERROR! ... The instruction at ... reference memory at ... The memory could not be read"

I haven't seen the error come up in previous iterations of my map before and when it does come up it does so at unpredictable times. Between the last time my map was working and now I have added a lot of features so I don't really know what could be causing the issue. These are the most significant triggers I added since the last time the map worked properly:

But the moments when the error occurs don't necessarily correspond to the events that cause these triggers so I'm sort of at a loss. I tried adding a custom script to the Bonus Round Loop trigger to destroy the unit group created in the if condition of said trigger (I understand that conditions like the one above cause memory leaks otherwise), but I couldn't get my map to "compile" with the custom script there so I deleted it for now. Does creating and removing a custom script have some sort of residual effect that I haven't cleaned up? Are there any other common mistakes that can lead to this error or other issues you've noticed?

I know that this is a bit of a long shot since I don't have much experience with this so I don't really know what info to provide, but if anyone has any suggestions I'd really appreciate it. Thanks!

 

[Chaosium]

I don't think memory leaks could outright make the game crash, cause performance issues in the long run sure but a fatal error, seems unlikely to me

Do you use custom models? If yes, have you tested that all of them display properly if you place them in the map? Faulty models can definitely be a source of crashing

My only guess for the time being is that one of your unit types at random shows up and causes issues

 

[Pyrogasm]

I tried adding a custom script to the Bonus Round Loop trigger to destroy the unit group created in the if condition of said trigger (I understand that conditions like the one above cause memory leaks otherwise)

Honestly, the point leaks are a bigger (but still tiny) issue than the group leak. Here's a simple reference for leak removal/avoidance which links to a good structured tutorial: Things That Leak. Since the group used in the check isn't stored in a variable, you will abuse a backdoor for auto-group-deletion that works for most GUI unit group actions; setting this boolean flag to true will tell the game to destroy the next group that is interacted with by these actions.

• Custom script: set bj_wantDestroyGroup = true //capitalization matters here
• If (All conditions)...
  • If - Conditions
    • (Number of units in ... )
  • Then - Actions
  • Else - Actions

Does creating and removing a custom script have some sort of residual effect that I haven't cleaned up?

No, it's just a blank line on which to write arbitrary JASS/Lua code. If you deleted the contents of the script call but not the call itself, it's possible you could leave an invisible space character in there which would fuck with the compiler, but that's extremely rare and contrived.

Are there any other common mistakes that can lead to this error or other issues you've noticed?

It's mostly a generic error. The kind of thing I know to cause this is attempting to call an illegal/nonexistant function with ExecuteFunc(). I presume you're not doing that anywhere, but if you have a bunch of JASS/Lua somewhere in your custom script header it could be worth searching for that function name to see if something you imported is using it.

Unfortunately, tracking down issues like this just takes a lot of patience and perseverance to finally catch it in the act and know what had just happened to trigger the crash. If you can start to reproduce it, finding the source is considerably easier; without reliable reproduction you might never figure out what it is. Keep tinkering and see if you notice an patterns.

 

[apostrophe841]

Thank you both for the replies, much appreciated. I am not using any custom models. I have a few custom units, but they are just rearrangements of the existing models/voices/abilities/etc. in the game, with a few numbers tweaked. The main unusual feature of my map is that when a hero levels up it gets a random ability, and when it levels up past level 5 it randomly loses one of its abilities and replaces it with another. Are there any combinations of existing abilities and heroes that cause the game to crash perhaps? I've played earlier versions of the map successfully multiple times, but with so much randomness maybe I just got "lucky" all those times. There's a lot of randomness in my map in general so tracking this down will be tricky for sure haha.

 

[Chaosium]

During your tests, are you using the HD reforged graphics? I've had random crashes playing with those even in the official maps without any rime or reason...

 

[apostrophe841]

Thanks for replying. No, I'm using the classic graphics.

 

[Verdun]

Now I got a different error a while back that said "running out of memory" but maybe be it can help for troubleshooting...

Do you have a 480 map? I discovered that triggers that scan regions that are too large crash the game (had to find what size through trial and error). Is your "Bonus Middle" region for instance especially big?

 

[Dr Super Good]

Bonus Round Loop seems to create a thread leak. Every time another thread runs this trigger, it will create a thread that will exist forever, until the map session ends. This means that every unit that enters Bonus Round Portal that passes the condition will create such a permanent leaked thread.

You probably want to change it to a state machine of sorts. Entering bonus round portal sets the game state to bonus round and then turns off the entry trigger and enables a periodic trigger that performs your bonus round loop logic. Entering the portal again while in the bonus round game state does nothing as the trigger is disabled. Once the bonus round is finished you leave that game state, turning off the periodic trigger running the loop logic, and enabling the entry trigger again.

 

[apostrophe841]

Thank you both for the replies. The map is not very large (I don't remember the exact dimensions) and the "Bonus Middle" region is very small. I appreciate the idea about the state machine-like setup and will try to do that, thanks! I've played the map a few more times without crashes (without making any changes) so I'm pretty sure the crash is due to a certain hero/ability combination that the engine doesn't like for some reason.

So, just to be clear about an earlier suggestion, to remove the unit group leak from my Bonus Round Loop trigger, I simply add this custom script before the if statement?

Custom script: set bj_wantDestroyGroup = true

Does that seem right?

 

[Pyrogasm]

Yes, that's the correct usage. Most of the GUI actions that create groups (which you could otherwise leak) check the value of bj_wantDestroyGroup, and will destroy their transient groups automatically if the value is true. Setting the global will affect the next such group created, so if you do that and then don't create a group with a function that checks its value, the next group created in the map may erroneously be destroyed! It works with conditions, too, but can't do more than one group in the same line.