Server Fails

Comments

• Krash

  March 25

  These two memory offsets indicate string formatting errors with inaccessible data. It'd be difficult to narrow it down further without the stack, but it's almost certainly going to be a script lexer issue; there's an outside chance something is causing a buffer overflow, but most likely a script is trying to process an uninitialized local variable or referencing data that has been deleted internally.

  Does this occur on specific maps, specific game modes, specific mods? With a map it might be possible an expected format isn't being followed (although I can't think of anything offhand that should lead to this error over others), but I'd otherwise suggest reviewing scripts that run at the point of load – and, keep in mind, .mis files themselves are processed by the script engine at load as well.
• BBlakhart

  March 25

  Thanks for the response, I on occasion see errors in console such as "ai objectives.cs unable to find object xxxxxx attempting to call function weight" and etc, almost all errors seen have something to do with ai. Not every map however has the above error messages, and the map I recall most crashing after load is Wonderland, of course with bots.
• Krash

  March 26

  It's possible they're related, because the AI systems would need to access data such as objectives on map loads, and because it means the person who wrote the scripts wasn't too worried about playing it safe using isObject checks, but as a general rule the script engine's very forgiving about missing objects in most scenarios, and as long as it's outputting console errors/warnings... it's at least still running.

  AI script crashes could be tricky though, lots of guesswork to track down if there's not an easily observable cause, and if it's happening after the bots are already moving they could conceivably trigger something else entirely depending on the mod. If the same console error were seen before every crash, it'd be the best starting point for walking forward and backward through what's expected to happen.

  If you're able to find any way to consistently reproduce the crash, I'd love to see how so I can check it locally on my end.
• BBlakhart

  March 27

  Next time it freaks out will post the server logs if I can remember to. For whatever reason it's usually either at map load or shortly after map load and play has begun - this happened to me yesterday say 30 secs after mission start. It hardly ever just crashes in the middle of a match, can't recall the last time it did that.
• BBlakhart

  April 27

  A fabulous new fail!

  
  

  This was during a siege bout it seems.

  
  

  fault offset 0x002ff34b

  exception 0xc0000005
• Krash

  May 1

  Hmm, unfortunately that one's not something that'll likely lead to any answers/fixes, as that offset puts you smack in the middle of the exception handler itself, specifically in building the message for the error popup dialog. Could be hitting something that corrupted the stack, but it's anyone's guess where...
• BBlakhart

  3:21AM

  Might this be the cause?

  
  

  //Disable UE box on crash

  //Used if a clean crash is desired

  memPatch("7dc7fc","90");
• Krash

  5:10AM edited 5:11AM

  Not of the initial exception, but it's likely that causes further issues inside the exception handler, yes.

  0x7DC7FC gets filled with a pointer to the imported MessageBoxA symbol, and writing 90 in that location would cause the game to attempt to call that pointer with one byte changed to another offset, which would result in undefined behaviour and in most cases ultimately just... crash. Which, sure, it's crashing anyways, but this is more the throwing a marble on the stairs and letting the process break its neck on the way down approach than a clean shutdown.

  While it'd be possible to write some other behaviour there instead, the quickest way to do disable that popup while the game is running would be to NOP the call itself with something like: memPatch("6FF376", "909090909090");