Closed dsizzle closed 1 year ago
It builds alright on 32bit Haiku. However, loading a compressed project file crashes. Same crash for loading a just saved file on 32bit, or a file created from a 64bit version: ArtPaint-1832-debug-10-06-2023-06-39-58.report.txt
Back on 64bit, loading a project saved under 32bit crashes similarly: ArtPaint-1911-debug-10-06-2023-06-46-37.report.txt
Sorry for spamming... Should you need it, here's a project file saved under 32bit: 16+1_Layers_compr_32bit.zip (Had to zip up to be able to upload to github...)
Yeah this is what I was afraid of. I should’ve spent more time of this fix. Anyway it’s not spam! Thanks for all the details!
Sorry, I haven't had much time lately, but I did make a fix and then I spun up a 32-bit Haiku and tried to build but I get millions of errors so something must be wrong with my environment somehow - can you please try again when you have a moment? You'd need to re-save the compressed files otherwise I'm sure the existing ones will crash.
I'll try it this evening. I bet you forgot to do a 'setarch x86' before compiling... 😃
I'm afraid it's still not there yet... No problem saving&loading a 64bit-file with 64-bit-ArtPaint. Loading a 32bit-file with 32bit- and 64bit-ArtPaint still crashes: 32bit-loading-32bit-file.report.txt 64bit-loading-32bit-file.report.txt This is a 32bit-file: test32bit.zip
Before building, I did a "build.sh clean all". Don't sweat it, if you don't have much time ATM, better relax a bit more AFK nad return to ArtPaint when your day job doesn't try to kill you anymore...
I think I got it to not crash on both platforms, but I also think it doesn't compress anymore... I should probably just disable the compression one of these days until I have time to actually look into it.
I'm afraid it still crashes similar as describe in my last comment...
I'm completely unqualified to give and constructive input here. Maybe other code in the Haiku tree may give some inspiration. Grepping for zlib returns:
❯ grep -r "zlib.h"
add-ons/kernel/file_systems/btrfs/system_dependencies.h:#include <zlib.h>
add-ons/kernel/file_systems/btrfs/system_dependencies.h:#include <zlib.h>
add-ons/translators/wonderbrush/support/bitmap_compression.cpp:#include <zlib.h>
apps/packageinstaller/PackageItem.cpp:#include "zlib.h"
bin/unzip/crc32.c: * For conditions of distribution and use, see copyright notice in zlib.h
bin/unzip/crctab.c: * For conditions of distribution and use, see copyright notice in zlib.h
bin/unzip/globals.h:# include "zlib.h"
kits/support/ZlibCompressionAlgorithm.cpp:#include <zlib.h>
system/boot/loader/file_systems/tarfs/tarfs.cpp:#include <zlib.h>
system/boot/platform/generic/video_splash.cpp:#include <zlib.h>
tests/add-ons/kernel/file_systems/btrfs/btrfs_shell/Jamfile: Z_SOLO # prevent inclusion of system headers from zlib.h
tools/generate_boot_screen.cpp:#include <zlib.h>
Maybe the wonderbrush translator has some insights?
"Hang on. Hang the futtock on!"
I was wondering why this PR has a commit date of March and rebased on master. A clean build now shows no crashes any more! And 32bit ArtPaint can open 64bit projects and vice versa. No compression anymore though, as you said...
Just a note: there is a BZlibCompressionAlgorithm in private Haiku Support API. If you have interest, it's possible to open it at least experimental.
Ok, I think it's fixed. Embarrassingly I was writing the data using the pre-compressed length.
@korli thanks, but the zlib part wasn't the problem, it was me doing dumb stuff. :smile:
Unfortunately, we're back to project files saved with the 32bit ArtPaint crashing ArtPaint (32 and 64bit). Project files saved with 64bit ArtPaint can be opened on both 32 and 64bit... Don't let it spoil your weekend. ;)
64-bit is better anyway. :stuck_out_tongue_closed_eyes:
Also it doesn’t spoil my weekend - I only changed one value between the No-crash-but-no-compression version and this one, so that means that is exactly the value that I need to fix.
... so that means that is exactly the value that I need to fix.
Unshakable confidence. I like it. :)
ok, I really think this is the fix, for realsies
Yay, you did it !! \o/ \o/ \o/ Finally. *ducks :)
I believe this should fix #544
...but I don't have a 32-bit version to test