How to track down a crash that only occurs in a release build?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By alwaysusa

Hey all,

I have a first playable demo of my game ready to send out to a few testers for feedback - but when I export a release build the game randomly crashes. It works fine in editor, and fine when exporting to a debug build - the issue only happens in release.

I have no idea how to track this down. I have no errors in the editor (I even cleaned up all warnings so it runs with zero issues that I know of) - but the Release build crashes every time. I vaguely know the repro steps for the crash, but without further data, I’m having problems debugging.

So, any ideas on what one does in this situation? If I could get it to crash in the debug build - I still wouldn’t know what to do as there doesn’t seem to be any logs generated?

Cheers for any help!

EDIT: More info:
I had an engineer friend take a look and he noted that an invalid memory call was causing the issue - possibly from a null reference. He then figured out I could turn on verbose logging (by running the exe from a cmd prompt and using -v).

Now the problem is when using -v, it won’t crash. Without logging, it crashes. Same executable.

What could cause that?

I have exactly the same problem, and it seems to be related to a queue_free() call, deleting a node.

In my case, I want to delete a node. When I use queue_ free() it crashes (in release build only), when I use remove _child(), it works (at least for testing).

Edit: I also delete other nodes with queue_free() without problems so there has to be more to it, but I could not pinpoint it yet. It could be related to collisions (the problematic node collides with another when deleted, while the others don’t).

Lorgarmor | 2020-11-29 20:05

:bust_in_silhouette: Reply From: JimArtificer

Some general steps that you could try to narrow down the problem:

  • Export a release build with a different version of Godot.
  • Export a release build to a different target platform to see if it is platform specific.
  • (C#-specific) Upgrade the language version to 8.0 and enable nullable reference type checking to help you identify where null pointer exceptions could occur. This is a fairly extreme option.
    Update your codebase to use nullable reference types - C# | Microsoft Learn
  • Report the issue on Github. This sounds like something the devs would be motivated to fix.
    Sign in to GitHub · GitHub

To strictly answer your question about cause: a race condition could be the culprit.

Those are great tips - thank you so much!

I’d never heard of a race condition so I looked it up - and that does seem like a distinct possibility. The crash does seem to occur in the middle of a bit of ‘chaos’ where a variable is being referenced in one script, changed by another, then acted on by the first script when it’s already changed (or possibly, freed). It’s just odd that it’s only on release.

Great tips and I’ll dig into the suggestions. Thanks again :slight_smile:

alwaysusa | 2020-07-19 05:54

This kind of crash is often related to dangling Variants. A fix was integrated in 3.2.2, but it only works in debug builds for performance reasons. (A different fix which also works in release builds will be integrated in 4.0.)

Calinou | 2020-07-19 11:59

I have just ran into the same problem using godot 3.2.2 stable release for an iphone game. However hope a bigger announcement is made on this bug. It will save alot of head ache.

hsojo91 | 2020-09-09 19:44