Crash in ImageExporter::_convert_tex when decompiling Psychopomp Gold #202
Comments
|
To be clear, you're building from the current gdsdecomp master with Godot @ the commit listed in the readme, correct? |
|
Yes, master with the particular commit -- it also seems to happen with the release and (at the time of writing) latest Actions build. |
|
Ah, heck, I thought this was fixed in the godot engine. Lemme guess, that particular texture is 1x1 pixels, right? |
|
I initially thought so too after searching for a bit, but // Compressed images' dimensions should be padded to the upper multiple of 4.
// If they aren't, they need to be realigned (the actual data is correctly padded though).
if (width % 4 != 0 || height % 4 != 0) {
int new_width = width + (4 - (width % 4));
int new_height = height + (4 - (height % 4));
print_verbose(vformat("Compressed image's dimensions are not multiples of 4 (%dx%d), aligning to (%dx%d)", width, height, new_width, new_height));
width = new_width;
height = new_height;
}The stack trace suggests it's 384x128: Which checks out because it's a padded up 381x127 (quickly tossed into the Editor to check): |
|
I had a random thought and cleared mipmaps in |
|
This is definitely a bug in Godot. I would recommend filing an issue that cross-references godotengine/godot#97862 and godotengine/godot#97873. Protip: mention that it causes a heap buffer overflow in the title. That always gets their attention. |
|
How do I do this? Clear mipmaps, I mean. |
|
I got my hands on Psychopomp Gold and attempted to recreate this to no avail. I think I might have fixed it on the latest PR? Could you try the artifacts here and see if you still have the problem? https://github.com/bruvzg/gdsdecomp/actions/runs/11611147300?pr=208 |
Still experiencing this with these artifacts (both linux and windows/wine), as well as my own build on latest master ( 3175997 ) (only tried linux) |
|
However, I tried this on an actual Windows VM, and indeed it doesn't happen. Really odd it also happens in wine. |
|
ah hah; I think it's related to another bug that I just fixed wrt case-sensitive names, give this one a shot: https://github.com/bruvzg/gdsdecomp/actions/runs/11623418896?pr=209 |
|
No dice. Also, since the project changed a bit since the initial stack trace, here's an up-to-date one (not that anything's different): |
|
It’s odd this only happens on Linux, and fixes itself when mipmaps cleared. The “free” in the stack trace suggests a double free. |
I haven't been able to track down the cause, but here's a Valgrind log in the meantime (however, from a pre-multi-threaded version, c61f14a, so that it's more clear): |
|
Yeah, this is related to godotengine/godot#97862 , I'm seeing the same sort of invalid writes that I saw there. They might have missed something related to mipmaps data when doing the resize; the PR DOES assume the actual image data would be of the proper length. I would recommend making an MRP (which shouldn't be too difficult; basically, copy the original .ctex file into a project, then make a script that loads the texture, gets the image, then decompresses it) and submitting the issue to godot. I would do this myself, but I can't reproduce this on MacOS and I'm not going to be near a computer that can run Linux for at least a month. |
This is happening to me on Windows. Even with the other builds. |
|
OK, I was finally able to track this down when building with sanitizers. It is related to the previous issue; basically, the last mipmap at the end of the mipmap list has dimensions that are non-divisible by 4, causing it to write past the allocated destination memory. I will submit an issue and hopefully get this fixed soon. |
|
Tracking godotengine/godot#98884 ; when this is closed, I'll just resync with master. |
|
give this artifact a shot: https://github.com/bruvzg/gdsdecomp/actions/runs/11698791421/job/32579668792?pr=215 I decided to take @Alex-gnzl 's advice and just |
|
This is not fixed, I'm still getting the crash when trying to decompile Psychopomp Gold. |
System information
Arch Linux, 6.11
Issue description
A certain asset (assets?) in Psychopomp Gold causes the engine to abort
GDB trace from own build:
(First?) asset that causes this:
res://Sprites/Items/ParagonKeyAnim.pngSteps to reproduce
Try to recover
Psychopomp Gold.exeusing either the Windows or Linux version of gdsdecompRecovery log
N/A
Minimal reproduction project
https://store.steampowered.com/app/3243190/Psychopomp_GOLD/
I wish I could provide an example texture that causes this, but I'm not sure what settings result in this happening.
The text was updated successfully, but these errors were encountered: