akien-mga
commented
6 years ago Can you still reproduce it in Godot 3.0 beta 2?
Closed tom95 closed 6 years ago
akien-mga
commented
6 years ago Can you still reproduce it in Godot 3.0 beta 2?
akien-mga
commented
6 years ago I've tried your master branch on Godot's current master branch and couldn't reproduce a crash in the editor. Then I read that it crashed in exported builds, so I tried with a 3.0 beta2 Linux 64-bit release binary, but it also worked fine (it shows many errors in the console with might be linked to different issues though, likely specific to that project). I've tried the build from itch.io which also worked fine.
So I guess it got fixed somehow?
tom95
commented
6 years ago Most of the time the crash happened just before or just after the final boss battle (with the game open, hit f4 and then ctrl+alt+b to teleport right to him). I will test myself with beta2 and report back. Thanks a lot for the assistance!
akien-mga
commented
6 years ago Most of the time the crash happened just before or just after the final boss battle (with the game open, hit f4 and then ctrl+alt+b to teleport right to him).
Yeah that's what I tried, I got killed 10 times or so by the boss trying to reproduce it :P
tom95
commented
6 years ago With this build http://tombeckmann.de/c/debug.zip (any hoster you can recommend for test files?) I reliably get crashes on Ubuntu 16.04 64bit whenever I press enter after killing the boss (he is now one-hittable, thanks for playtesting :P ). The corresponding code is on this branch: https://github.com/tom95/thrown-back/tree/crash-debug (fixed some of the failing assertions you mentioned, removed the music for lighter export, added the debug print mentioned below).
This is the code that gets executed when pressing enter:
func _process(delta):
if Input.is_action_pressed("start"):
var game = load("res://game/game.tscn").instance()
get_parent().add_child(game)
game.show_level(FIRST_LEVEL)
game.show_instructions(SHOW_INSTRUCTIONS)
queue_free()I added print statements between each line, the last one that got printed was just before load() (I split the load/instance statement for testing). The corresponding trace from gdb:
#0 _int_malloc (av=av@entry=0x7fc9e3686b20 <main_arena>, bytes=bytes@entry=552) at malloc.c:3516
#1 0x00007fc9e3346184 in __GI___libc_malloc (bytes=552) at malloc.c:2913
#2 0x00007fc9e332fcdd in __fopen_internal (filename=0x2501100 "/home/tom/Code/godot/thrown-back/wizards.pck", mode=0x174fe71 "rb", is32=1) at iofopen.c:69
#3 0x0000000000831456 in ?? ()@cmfcmf said that he'll re-test the crashes on Windows 64bit with beta2 tomorrow :)
akien-mga
commented
6 years ago Thanks, using this debug branch I can reproduce the bug with the Linux 64-bit release template of 3.0 beta 2. With the debug template it's not crashing, so indeed it's hard to get proper debug information.
I'll try a local build of a release template with debug symbols (yeah, that can be done :P) and see how it goes.
akien-mga
commented
6 years ago I built a release binary with scons p=x11 target=release tools=no but could not reproduce the issue, whether I kept the debug symbols next to it or not. I'll try with LTO now, as the official binaries. Other possibility could be that I build my local binaries with GCC 5.4.0, while official binaries use GCC 7.1.
Edit: Also doesn't crash with LTO on GCC 5.4.0... It's starting to remind me of GCC 6+ specific crashes we had last year on release builds.
cmfcmf
commented
6 years ago Finally got around testing this on Windows 10 64bit running Godot Beta 2: I can reproduce the crash with debug disabled. I can not reproduce the crash with debug enabled, this is the output I receive in debug mode after killing the boss:
ERROR: time should be greater than zero.
At: scene\main\timer.cpp:83
done
ERROR: RID_Owner<struct RasterizerStorageGLES3::Material>::getornull: Condition ' !id_map.has(p_rid.get_data()) ' is true. returned: 0
At: c:\projects\godot-builds\godot\core\rid.h:164
ERROR: RID_Owner<struct RasterizerStorageGLES3::Material>::getornull: Condition ' !id_map.has(p_rid.get_data()) ' is true. returned: 0
At: c:\projects\godot-builds\godot\core\rid.h:164
a
b
c
d
e
f
zThanks, this rules out a GCC-specific issue as Windows builds are done with Visual Studio 2017.
The debug output can point us in the right direction though, release builds don't check for such errors so they can indeed crash, while debug builds will error out. So finding what causes those errors (either in the game scripts or in the engine itself) should help solve the issue.
hpvb
commented
6 years ago I have found more information about this crash, I need to reproduce with a build with more debugging symbols (no lineno information here) but I do have proper backtraces from valgrind about what I suspect is causing this problem:
https://paste.fedoraproject.org/paste/nK-8g3lJaqlprpL-gOawEw
I'll update once I have linenos
edit: Initial analysis of the valgrind information seems to suggest that RasterizerStorageGLES3::update_dirty_resources() tries to access a recently free'd material. It appears that the material gets freed in response to a node deletion.
hpvb
commented
6 years ago I've been able to reproduce the crash using 0b1e6ec2195a22ad66513685d0c0850eaeb9b528. The full valgrind output is here (now with line numbers) https://paste.fedoraproject.org/paste/7DKQYqfeK-DoIdkL0z90nw
However, on master (aebdc4c2126789b915b0fb753f0594fec0f0226d) the problem does not occur.
I'm pretty sure that this problem has been fixed in the meantime. I don't know what commit might've done it though. However, the fact that valgrind isn't showing any use-after-free errors on master suggests to me that it is actually fixed and not just a fluke.
akien-mga
commented
6 years ago Awesome, thanks for debugging all this.
@tom95 @cmfcmf Could you try again with a nightly build from http://godot3builds.digitecnology.com/ ?
tom95
commented
6 years ago Tried with
Build date: 2018-01-09 13:10:08
Git commit id (short): 4b414f45cand no crashes on linux \o/
hpvb
commented
6 years ago After reverting 75c624e119998c4286a3d13e33233f44924f324a on master the crash reappeared. It seems that this fixed the problem.
akien-mga
commented
6 years ago Awesome, fixed by 75c624e then.
cmfcmf
commented
6 years ago I can confirm this is fixed on Windows as well 👍 🎉
Operating system or device, Godot version, GPU Model and driver (if graphics related): Ubuntu 16.04 64 bit, Godot 3.0 Beta, NVIDIA card with nvidia-384 driver
Issue description: Crash in exported game, could not find any indication on why it's happening so far.
Steps to reproduce: No minimal project available that captures it unfortunately, the repo can be found here: https://github.com/tom95/thrown-back (To quickly get to the point where it crashes, press enter to start the game, then f4 to skip to fourth level, then ctrl+alt+b to teleport to the boss. Then navigate towards the right with arrow keys and shoot the boss once with the spacebar). A production build that crashes for me as well is alternatively readily available from here: https://itch.io/jam/game-off-2017/rate/199596
When using a debug build or running in valgrind or godot, the crash does not occur. A gdb session on the release build only yielded ??. If given further instructions, I will gladly try out other ways for acquiring more info. Interestingly a crash appears to occur for the WebAssembly export at the same place in the game. Disabling elements like the particles or sound when the boss dies did not fix the crash.
Dump: