Debugging segmentation fault in exported games

Karamel

It has been a few days I'm trying to fix segmentation faults happening only with exported games. I was able to fix a few (I think) about references to freed nodes by disabling things until it works and re-enabling them one by one, but it's becoming harder and harder without clues.

Is there a way to get more information about the source of segfaults? The game just crashes with a Segmentation Fault message on the console and no error nor warning in the log, nor relevant information when ran with --verbose. No dump either.

The fault doesn't occur when running the game from the editor, and doesn't occur either with executables exported with debug. The game just run fine without error nor warning (except a maybe unrelated bug with the Window build). The errors occurs only with executables exported without debug, with both Windows and Linux exports.

Is there a way to enable core dumping or an explanation about the differences between debug and non-debug exports?

Thanks for your time

TwistedTwigleg

Welcome to the forums @Karamel!

I'm not sure if this would work or not, but according to this old GitHub issue, running gdb may return output about the crash. I'm not sure if it is still relevant with Godot today, but maybe it will yield some information on what is going wrong?

Karamel

Thanks for the response.

I tried attaching gdb to the executable. I got a segfault at an unexpected new point \o/ but could reproduce the previous crashes, with the same gdb output.

For information, here is the output (gdb) backtrace #0 0x0000000001c2aa8b in dynamic_cast () #1 0x0000000000000000 in ?? () (gdb) info frame Stack level 0, frame at 0x7fffffffa488: rip = 0x1c2aa8b in dynamic_cast; saved rip = 0x0 called by frame at 0x7fffffffa490 Arglist at 0x7fffffffa478, args: Locals at 0x7fffffffa478, Previous frame's sp is 0x7fffffffa488 Saved registers: rip at 0x7fffffffa480 (gdb) info args No symbol table info available.

So, it's still better than nothing, but it's probably something about checking against a removed object.

I'll continue to check. It seems to be related to something about some collision exception in my game (I get "ERROR: remove_collision_exception_with: Parameter "p_node" is null." maybe once every 20 crashes, maybe something about flushing the output before crashing) and maybe every bug will vanish at once… Or not…

I may get around clearing collision exceptions instead of removing one (there is only one anyway) but it looks like putting the dust under the carpet… And that still doesn't explain why it crashes without debug and runs (almost) fine with.

TwistedTwigleg

Yeah, that is strange. I don't see anything in the gdb log that poins ot anything, at least not anything I recognize...

Calinou

Check for dangling Variants, such as the use of is_instance_valid() or comparing node references to null. Crashes in release builds are often caused by dangling Variants.

Karamel

It looks like it did the trick. I added defensive is_instance_valid checks everywhere I use a reference to a node and it hadn't crashed yet.

I still have an issue regarding collision exceptions once an invalid node get into the list. I get errors on get_collision_exceptions when trying to remove the faulty node. But this is an other topic and I guess I can find a way to do almost the same without requiring exceptions, removing them didn't changed the game really noticeably.

Thanks for the tip