ellraiser / love-build

zero-dependency cross-platform builder for LÖVE to export games to Windows, MacOS, and Linux
https://love2d.org
20 stars 4 forks source link

SquashFS decompress fails for love 12.0 #1

Closed Endaris closed 5 months ago

Endaris commented 5 months ago
love.squashfs > decompressing: "temp/squashdata", 6602752 bytes
love.squashfs > WARN: metadatablock was not compressed
6601979 772
love.squashfs > id:     128
love.squashfs > export table read: 57/57
love.squashfs > block size:     131072
love.squashfs > directory data:     737 1212
love.squashfs > WARN: file data doesnt match size expected  8   4432672 5846213 -1413541

As the if-branch giving out that warning returns nil instead of false, the app subsequently crashes as squashdata never finished decompressing. In particular I tried that with the AppImage from this workflow: https://github.com/love2d/love/actions/runs/8768067998 I can also reproduce it with a much older version from January. If I comment out the code for wiping temp and decompression, and inject a squashfs-root folder obtained through --appimage-extract into the temp folder, the build process for linux works fine and I can start the resulting AppRun. When using love 11.5 instead of 12.0, everything works fine.

System is debian 12 if that helps.

ellraiser commented 5 months ago

oh interesting, the 12 version I used originally for testing that squashfs module was from last year - will have a dig and see what might have changed with the new format

this was with the love-linux-x86_64.AppImage appimage file being put in your local, not the debug version right?

Endaris commented 5 months ago

Correct, not the debug version, just extracted from the zip and renamed so it would get found.

ellraiser commented 5 months ago

Ah yeah can see that error too, thanks!

Currently I'm checking the metadata header to see the 'expected' file size when deflated and if the bytes read don't match then I abort the decompression here: https://github.com/ellraiser/love-build/blob/main/libs/love-squashfs.lua#L663

It should always match, and definitely shouldnt ever be smaller, however in this case the actual deflated archive size is a bit bigger than the expected size in the header. The files all look correct though if I don't exit early, so I think it might just be a case of certain fragment entries actually having a header size of multiple fragments. Will have a play with it and get it fixed!

ellraiser commented 5 months ago

Okay this is fixed now in the latest release: https://github.com/ellraiser/love-build/releases/tag/v0.4

Issue was actually that the bigger size wasn't the deflation, but extra data not needed, so good to catch now! Only came up in 12.0 due to the larger file sizes