godot: application crash with "corrupted double-linked list"

Godot version

4.0 beta 2 mono

System information

Ubuntu 22.04.1 / GTX 960 / Vulkan

Issue description

Godot application (not editor) crashes with either “corrupted double-linked list” or “malloc(): smallbin double linked list”.

Here is the output from the console (2 different occurrences)

`Godot Engine v4.0.beta2.mono.official.f8745f2f7 - https://godotengine.org Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 960 libdbus-1.so: cannot open shared object file: No such file or directory libdbus-1.so: cannot open shared object file: No such file or directory

ERROR: Condition “!d.has(“handle_modes”)” is true. Returning: false at: _set (scene/resources/animation.cpp:319) ERROR: Condition “!d.has(“handle_modes”)” is true. Returning: false at: _set (scene/resources/animation.cpp:319) WARNING: res://Scripted agents/Systems3D/Guns/Gettling/Gettling.tscn:4 - ext_resource, invalid UUID: uid://dabx56bsjisvu - using text path instead: res://Scripted agents/Systems3D/Guns/Gettling/GettlingTurret.tscn at: load (scene/resources/resource_format_text.cpp:448) WARNING: res://Scripted agents/Systems3D/Guns/Gettling/GettlingTurret.tscn:10 - ext_resource, invalid UUID: uid://6m0p06s5bt5v - using text path instead: res://Graphics/materials/exhaust_process_shader.tres at: load (scene/resources/resource_format_text.cpp:448) malloc(): smallbin double linked list corrupted Aborted (core dumped)`

sometimes that second last line is corrupted double-linked list

Steps to reproduce

Despite how often it happens, the bug is hard to reproduce and happens at will It seams however, that it always triggers on Signal Emission in C#. I have also tried and failed to reproduce this in a smaller project.

Minimal reproduction project

No response

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 28 (3 by maintainers)

Most upvoted comments

I have a reproduction, it is not straightforward but it should be better than nothing. I am on Linux Mint (pretty much the same as Ubuntu)

  1. Download the project branch https://gitlab.com/gametheatre/poriferareader/Porifera/-/tree/bug_67263
  2. After the list populates, click the ‘Republish’ button on the right side of any item
  3. On the resulting popup, click the ‘TestPublish’ checkbox
  4. click another Republish button on another item without closing the popup
  5. repeat steps 3 - 4 rapidly until crash, usually happens with 5 attempts

The error message ‘corrupted double linked list’ only shows very rarely, usually there is no error message at all. It stands to reason that the cause of the crash is the same every time though.

n.b. Please don’t judge my application based on this branch, I have deliberately disabled most of the functionality to make this reproduction simpler.

edit: this reproduction is probably not valid, see below

Yes, that’s it. It actually fixes the issue. Amazing 👍

This fixed it for me to. Thanks so much for sorting this.

I opened PR https://github.com/godotengine/godot/pull/69194 that may fix this issue, can you try it out to confirm?

Linux users can download the artifact built by CI: https://github.com/godotengine/godot/suites/9514119809/artifacts/451640372 For other platforms, you’ll have to build Godot yourself.

For me this turned out to be due to threads accessing the scenetree in an unsafe way. Someone on discord informed me that the scenetree is not thread safe and should never be accessed outside the main thread. This means my UI updates needed to be deferred. If you are confused about how to do this effectively in C# (this took me a while to find out) the specific solution I used can be found here

tl:dr ignore the reproduction I posted, if my solution does not work for other people here then I never had the same issue as them, or at least had it so rarely that I haven’t seen it since. At the very least the reproduction does not appear to reflect an ongoing issue (other than perhaps the log messages being non-existent/unhelpful)

I had totally forgotten that I was using RTL in my project, and that there was a change to the way the BBCode was parsing. They did add a Threaded option to RTL when parsing BBCode, which would explain why there would be what I was thinking was a Thread Racing condition. This could be very well the culprit. @Dunkhan, have you tried using Beta 4, to see if it does as I reported, and just locks up, instead of crashing to the memory corruption error, or just locking Godot up completely?

After seeing @Dunkhan having the same error in 3.5.1, and me running into a similar issue, I went down a rabbit hole, and think I have possibly tracked the problem. This is a theory, as I have nothing to fully prove this to be the case, but in my particular case, I’m coding in Godot 4.0 with TwitchLib and OBS-WebSocket-Net, when I ran into this error, I backed to 3.5.1, and was making progress with my development, till it started crashing randomly out of no where. It would take multiple attempts to cause the error to popup, not like with Godot 4, where it would happen almost immediately. But when I received a signal that OBS was changing scenes, I would change the scene in Godot as well. On 4.0, this caused the corrupted double-linked list error. When backported to 3.5, it would take a few changes to the scene, and would randomly crash on the Scene changed. I tested with Keyboard input in Godot to see if just changing the scenes was the cause of the issue, and when I did it with the keyboard, it had no issue, it would change scenes no matter what, not matter how slow or fast I would do it, the program would never crash.

Then I got the idea from @Dunkhan, to use CallDeferred. In the 3.5.1 project, it instantly solved the problem, I would get no further crashes, but in the 4.0, it would stabilize the program, and wouldn’t instantly crash. Eventually, it would crash, so it made me think that maybe there was a Thread issue going on, where an attempt to free memory was happening, that caused the a Race Condition, as no proper mutex locking was occurring. Then it reminded me of the other two Memory bugs that I saw on the tracker in regards to 4.0, #67460 and #67563. Both of these are similar issues where Godot is crashing when attempting to free memory. It may be, that we need in the backend a way to lock memory during a GC Collection, to ensure that no cross-thread shenanigans are causing the memory corruption from occurring.

I will make a reproduction of the issue with Godot 4.0 and 3.5.1, using just OBS-WebSocket-Net, though it will require having OBS Studio installed with OBS-WebSocket setup to test, but may be able to give valuable information.

After digging deeper, my issue went away once I removed the only invocation of RPC. The repro posted by @Dunkhan also contains a network call. I’ve managed to create a minimal reproduction at https://github.com/seikho/godot-crash-repro.

The crash happens at a seemingly “random” time which leads me to believe it could be related to #67563 as well.

Also @Dunkhan, I could not access your reproduction project. It’s probably private. Maybe just upload the zip instead