Bug 503204

Summary: Krita Next nightly Appimage cannot start, memory allocation failed and bad address
Product: [Applications] krita Reporter: Tyson Tan <tysontanx>
Component: * UnknownAssignee: Krita Bugs <krita-bugs-null>
Status: RESOLVED UNMAINTAINED    
Severity: crash CC: dimula73
Priority: NOR    
Version First Reported In: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Manjaro   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Tyson Tan 2025-04-23 03:37:14 UTC
Since Apr 17, 2025, Krita Next nightly appimages cannot start anymore. Older ones still works.

Environment:

Operating System: Manjaro Linux 
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.12.0
Qt Version: 6.9.0
Kernel Version: 6.14.0-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 46.9 GiB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: GPD
Product Name: G1619-04
System Version: Ver.1.0

Run them in console returns the following message:

./krita-5.3.0-prealpha-036380b067-x86_64.AppImage                                                                 
fuse: memory allocation failed
squashfuse 0.5.2 (c) 2012 Dave Vasilevsky

Usage: squashfuse [options] ARCHIVE MOUNTPOINT

(null) options:
    -o offset=N            offset N bytes into ARCHIVE to mount
    -o subdir=PATH         mount subdirectory PATH of ARCHIVE
    -o notify_pipe=PATH    named pipe that will receive 's' (success)
                           or 'f' (failure) when the mountpoint is ready
    -o timeout=N           idle N seconds for automatic unmount
    -o uid=N               set file owner to uid N
    -o gid=N               set file group to gid N

FUSE options:
    -h   --help            print help
    -V   --version         print version
    -d   -o debug          enable debug output (implies -f)
    -f                     foreground operation
    -s                     disable multi-threaded operation
    -o clone_fd            use separate fuse device fd for each thread
                           (may improve performance)
    -o max_idle_threads    the maximum number of idle worker threads
                           allowed (default: -1)
    -o max_threads         the maximum number of worker threads
                           allowed (default: 10)
fuse: memory allocation failed
squashfuse 0.5.2 (c) 2012 Dave Vasilevsky

Usage: squashfuse [options] ARCHIVE MOUNTPOINT

(null) options:
    -o offset=N            offset N bytes into ARCHIVE to mount
    -o subdir=PATH         mount subdirectory PATH of ARCHIVE
    -o notify_pipe=PATH    named pipe that will receive 's' (success)
                           or 'f' (failure) when the mountpoint is ready
    -o timeout=N           idle N seconds for automatic unmount
    -o uid=N               set file owner to uid N
    -o gid=N               set file group to gid N

FUSE options:
    -h   --help            print help
    -V   --version         print version
    -d   -o debug          enable debug output (implies -f)
    -f                     foreground operation
    -s                     disable multi-threaded operation
    -o clone_fd            use separate fuse device fd for each thread
                           (may improve performance)
    -o max_idle_threads    the maximum number of idle worker threads
                           allowed (default: -1)
    -o max_threads         the maximum number of worker threads
                           allowed (default: 10)
squashfuse 0.5.2 (c) 2012 Dave Vasilevsky

Usage: squashfuse [options] ARCHIVE MOUNTPOINT

(null) options:
    -o offset=N            offset N bytes into ARCHIVE to mount
    -o subdir=PATH         mount subdirectory PATH of ARCHIVE
    -o notify_pipe=PATH    named pipe that will receive 's' (success)
                           or 'f' (failure) when the mountpoint is ready
    -o timeout=N           idle N seconds for automatic unmount
    -o uid=N               set file owner to uid N
    -o gid=N               set file group to gid N

FUSE options:
    -h   --help            print help
    -V   --version         print version
    -d   -o debug          enable debug output (implies -f)
    -f                     foreground operation
    -s                     disable multi-threaded operation
    -o clone_fd            use separate fuse device fd for each thread
                           (may improve performance)
    -o max_idle_threads    the maximum number of idle worker threads
                           allowed (default: -1)
    -o max_threads         the maximum number of worker threads
                           allowed (default: 10)
Can't open squashfs image: Bad address

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information
execv error: No such file or directory
Comment 1 Dmitry Kazakov 2025-04-23 07:29:41 UTC
Hi, Tyson!

Could you check if you have AppImageLauncher installed? 

This link says it could cause an issue like that:
https://forum.cursor.com/t/0-47-9-failed-to-launch-fuse-memory-allocation-failed/68394/17
Comment 2 Tyson Tan 2025-04-23 07:47:16 UTC
Yes, I'm using AppimageLauncher on Manjaro.
So it seems to be a unrelated issue to Krita?
Weird that the old appimage still works though.
Comment 3 Dmitry Kazakov 2025-04-23 11:49:04 UTC
Hi, Tyson! 

Could you please tell what version of AppImageLauncher you use? And could you try to update to the latest available Alpha version of AppImageLauncher?

PS:
We have updated Krita to the new version of AppImage runtime, that is the reason why older versions work fine. Though I believe that we should resolve this problem before doing the release.
Comment 4 Tyson Tan 2025-04-23 11:55:46 UTC
I'm using a customized version of appimagelauncher from AUR:
http://aur.archlinux.org/packages/appimagelauncher

The version number is 2.2.0-9, the codebase was from 2020.
Years ago I sent an updated Chinese translation to the project, and attempt to discuss how they might have handled locale incorrectly, never saw a reply.

I think the project is probably dead.
Comment 5 Dmitry Kazakov 2025-05-09 09:13:33 UTC
Hi, Tyson!

> I think the project is probably dead

As far as I can tell, the project in not dead, it is just the author is not careful enough with versioning of the package. Here is his note:
https://github.com/AppImage/type2-runtime/issues/121#issuecomment-2864143920

Could you help me with one question? Do you have any workaround running the new AppImage package on your system? E.g. by clicking on it directly, bypassing the launcher?
Comment 6 Tyson Tan 2025-05-09 11:49:24 UTC
Yes, I can just run the AppImage directly, if I uninstalled AppImageLauncher.

I decided to stop using the launcher due to its added complexity. I can't build the newer version because I can't direct access to Github from China, and I don't want to figure out how to make curl use a proxy during an AUR package build.
Comment 7 Dmitry Kazakov 2025-05-12 08:50:13 UTC
Well, given that AppImage developers have no will to fix this issue, I guess we can call it unsupported and declare that the user should update AppImageLauncher instead :(