Godot crashes upon opening this project #10758
Labels
Milestone
Comments
|
This seems to be an assertion in etc2comp while encoding 5CA0DDAE_c.png Full backtrace: |
|
Importing that same image into a different project does not cause the assert to be triggered. Looks like it must be something else. |
|
At least, it doesn't crash on MSVC/Windows x64. GCC version? |
|
GCC 7 in both cases I imagine. I've removed that image from the project and it does not crash, I've imported that single image into another project and it also doesn't crash. The previous GCC issues we had were due to the UB in Object::cast_to(), I have no idea what this is. I've also build etc2comp separately and tried to reproduce the crash with the cli tool it comes with. Same compiler, no crash. This will require a lot more digging. |
|
It appears that building etc2comp with -ffast-math doesn't work correctly on this compiler. Building without fixes the issue for me. |
hpvb
added a commit
to hpvb/godot
that referenced
this issue
Aug 30, 2017
Apparently -ffast-math generates incorrect code with recent versions of GCC and Clang. The manual page for GCC warns about this possibility. In my tests it doesn't actually appear to be measurably slower in this case, and this is used in a batch process so it seems safe to disable this. This fixes godotengine#10758 and fixes godotengine#10070
hpvb
added a commit
to hpvb/godot
that referenced
this issue
Jan 9, 2019
Godot supports many different compilers and for production releases we have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers all do slightly different things with -ffast-math and it is causing issues now. See godotengine#24841, godotengine#24540, godotengine#10758, godotengine#10070. And probably other complaints about physics differences between release and release_debug builds. I've done some performance comparisons on Linux x86_64. All tests are ran 20 times. Bunnymark: (higher is better) (bunnies) min max stdev average fast-math 7332 7597 71 7432 this pr 7379 7779 108 7621 (102%) FPBench (gdscript port http://fpbench.org/) (lower is better) (ms) fast-math 15441 16127 192 15764 this pr 15671 16855 326 16001 (99%) Float_add (adding floats in a tight loop) (lower is better) (sec) fast-math 5.49 5.78 0.07 5.65 this pr 5.65 5.90 0.06 5.76 (98%) Float_div (dividing floats in a tight loop) (lower is better) (sec) fast-math 11.70 12.36 0.18 11.99 this pr 11.92 12.32 0.12 12.12 (99%) Float_mul (multiplying floats in a tight loop) (lower is better) (sec) fast-math 11.72 12.17 0.12 11.93 this pr 12.01 12.62 0.17 12.26 (97%) I have also looked at FPS numbers for tps-demo, 3d platformer, 2d platformer, and sponza and could not find any measurable difference. I believe that given the issues and oft-reported (physics) glitches on release builds I believe that the couple of percent of tight-loop floating point performance regression is well worth it. This fixes godotengine#24540 and fixes godotengine#24841
hpvb
added a commit
to hpvb/godot
that referenced
this issue
Jan 9, 2019
Godot supports many different compilers and for production releases we have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers all do slightly different things with -ffast-math and it is causing issues now. See godotengine#24841, godotengine#24540, godotengine#10758, godotengine#10070. And probably other complaints about physics differences between release and release_debug builds. I've done some performance comparisons on Linux x86_64. All tests are ran 20 times. Bunnymark: (higher is better) (bunnies) min max stdev average fast-math 7332 7597 71 7432 this pr 7379 7779 108 7779 (109%) FPBench (gdscript port http://fpbench.org/) (lower is better) (ms) fast-math 15441 16127 192 15764 this pr 15671 16855 326 16855 (99%) Float_add (adding floats in a tight loop) (lower is better) (sec) fast-math 5.49 5.78 0.07 5.65 this pr 5.65 5.90 0.06 5.76 (98%) Float_div (dividing floats in a tight loop) (lower is better) (sec) fast-math 11.70 12.36 0.18 11.99 this pr 11.92 12.32 0.12 12.12 (99%) Float_mul (multiplying floats in a tight loop) (lower is better) (sec) fast-math 11.72 12.17 0.12 11.93 this pr 12.01 12.62 0.17 12.26 (97%) I have also looked at FPS numbers for tps-demo, 3d platformer, 2d platformer, and sponza and could not find any measurable difference. I believe that given the issues and oft-reported (physics) glitches on release builds I believe that the couple of percent of tight-loop floating point performance regression is well worth it. This fixes godotengine#24540 and fixes godotengine#24841
akien-mga
pushed a commit
to akien-mga/godot
that referenced
this issue
Jul 3, 2019
Godot supports many different compilers and for production releases we have to support 3 currently: GCC8, Clang6, and MSVC2017. These compilers all do slightly different things with -ffast-math and it is causing issues now. See godotengine#24841, godotengine#24540, godotengine#10758, godotengine#10070. And probably other complaints about physics differences between release and release_debug builds. I've done some performance comparisons on Linux x86_64. All tests are ran 20 times. Bunnymark: (higher is better) (bunnies) min max stdev average fast-math 7332 7597 71 7432 this pr 7379 7779 108 7621 (102%) FPBench (gdscript port http://fpbench.org/) (lower is better) (ms) fast-math 15441 16127 192 15764 this pr 15671 16855 326 16001 (99%) Float_add (adding floats in a tight loop) (lower is better) (sec) fast-math 5.49 5.78 0.07 5.65 this pr 5.65 5.90 0.06 5.76 (98%) Float_div (dividing floats in a tight loop) (lower is better) (sec) fast-math 11.70 12.36 0.18 11.99 this pr 11.92 12.32 0.12 12.12 (99%) Float_mul (multiplying floats in a tight loop) (lower is better) (sec) fast-math 11.72 12.17 0.12 11.93 this pr 12.01 12.62 0.17 12.26 (97%) I have also looked at FPS numbers for tps-demo, 3d platformer, 2d platformer, and sponza and could not find any measurable difference. I believe that given the issues and oft-reported (physics) glitches on release builds I believe that the couple of percent of tight-loop floating point performance regression is well worth it. This fixes godotengine#24540 and fixes godotengine#24841 (cherry picked from commit e5b335d)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Operating system or device, Godot version
Linux Mint 18.2 Cinnamon x64 - Godot master 28c8592
Issue description:
A project of mine will just crash Godot upon opening it. Attempts to debug with gdc did not pan out as I'm an idiot who is bad at computer
The issue was introduced in 28c8592, but it can be replicated even in the latest commit as of this point (e8b05ca)
Steps to reproduce:
Link to minimal example project:
3D platformer.zip
The text was updated successfully, but these errors were encountered: