Images imported as lossless WebP crash release builds on some machines #55305
Comments
|
CC @godotengine/import @mortarroad - this is going to be fun to debug :| @lekoder In "v3.5.beta.custom_build.67f19ee51", the hash doesn't seem to match an upstream commit, I guess it's from your fork? What's the matching upstream commit you rebased on? In particular, does it include the recently merged 724c207 (just to see if that could have fixed an upstream libwebp bug). If the user is still willing to assist in debugging, it would be good to figure out a way to actually get a stacktrace. Official builds should create a stacktrace, albeit an unhelpful one due to stripping debug symbols. But a debug build should have a stacktrace with symbols even on Windows, but maybe not if you compiled with MSVC? |
No it's from my own fork and it does not include [724c207]. User agreed to assist in further testing, so I'm going to rebuild upstream 3.x and check if [724c207] helps. |
I usually get stacktraces from the debug builds I make, so this is probably not a MSVC preventing it. In this case it did not output anything at all. |
|
Crash backtraces are currently not written to log files. This means that for Windows release builds (which can't output anything to standard output), you must use a debugger such as Visual Studio, WinDbg (MSVC |
Sadly this means we won't be getting stack trace for this particular problem - while I can ask player to switch to a specific Steam branch, I don't think it's reasonable to expect him to install and connect a debugger. |
Calinou
changed the title
|
Can you provide example webp files? |
It seems expected to me that the crash backtrace isn't in the log written by Godot (Godot crashed so it can't write a log), but shouldn't it be written to |
|
We checked that, this is what we got from stdout/err: Note that part of the last line is cut off. |
@qarmin these are png files imported into the engine using webp compression. The source is a |
|
I updated the branch information in the original issue since we had an upgrade of the stable branch to publish fix; there is a branch specifically made for this issue that points to a broken build, for both the demo and full version of the game. |
|
Stack trace is printed by our code, for release builds we should be able to write it to the file instead of stderr. godot/platform/windows/crash_handler_windows.cpp Lines 181 to 212 in ca70756 |
Godot version
3.4.stable.official, v3.5.beta.custom_build.67f19ee51
System information
Windows 8 Pro 64-bit (6.2, Build 9200), Intel(R) Core(TM) i5-3570K, AMD Radeon HD 7800 Series, GLES3
Issue description
One player reported via Steam forums application not responding during startup.
I was unable to replicate this on any of my machines. Got in contact with the player and managed to bisect a specific version of game which ceased to work, and checked the difference between working and not-working PCK files. Only relevant changes were
.stexfiles:.importdirectory from last known working version and re-imported everything. It crashed.force pngin project settings, removed.importand re-imported everything. This worked.force png- also worked.In case of crash logs are cut off without any error report. This happens both for release builds and for debug builds. Here is the debug build output (run with
--verbose --debug):Steps to reproduce
I can't reproduce it locally - the only way I was able to debug is to send builds via Steam to the player and await feedback. Here is what I gathered about the machine that was used to run:
Minimal reproduction project
No MRP due to not even crashing on my own machine.
I know that version 0.427.2 (
stable branchgodot-debug branch, branch password:godotdebugbranch) and 0.427.7 (beta branch) currently crash the affected systems and 0.428.1 (experimental branch) does not crash them. This affects both full builds and free demos. Game link. We tested both a GodotSteam build, an official Godot binary and GodotGog build with same results.The text was updated successfully, but these errors were encountered: