Bug 460631 - Krita command line export freezes while Krita GUI is open
Summary: Krita command line export freezes while Krita GUI is open
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 5.1.1
Platform: Kubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: vanyossi
Depends on:
Reported: 2022-10-18 00:00 UTC by Geekley
Modified: 2023-02-09 12:36 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Geekley 2022-10-18 00:00:31 UTC
(a) When running a command-line command like --export or --export-sequence, the process does not run until Krita is closed. This makes it impossible to use the commands (e.g. from external apps) while working in Krita. It doesn't matter which file is open in Krita, it just won't execute the command while GUI is open for some reason.
This happens both on 5.1.1-flathub and 5.0.2-apt at least. I don't know when the bug was introduced.

(b) A very similar problem also happens (at least in 5.1.1-flathub; don't know if it's because of flatpak) where it freezes on splash screen when either:
- Krita GUI is open (with or without files open) and `flatpak run org.kde.krita` is run
- A Krita file is open in the GUI and `flatpak run org.kde.krita samefile.kra` is run to open the same file

All of these only unfreeze after Krita GUI is closed.

1. Open Krita GUI (e.g. from app launcher)
2. Open terminal and run the command (e.g. `krita --export file.kra --export-filename file.webp`; also happens with other commands)

Process is stuck (if command was to open GUI, it's stuck on splash screen), and only unfreezes when Krita is closed.

No Krita command-line commands should ever freeze. Export commands should work regardless of whether Krita GUI is open. Ideally, export commands should even be allowed to run in parallel. Same for export-sequence (animation frames).

Krita: 5.0.2 (apt) and 5.1.1 (Flathub)
Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.6
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Kernel Version: 5.15.0-50-generic (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-5300U CPU @ 2.30GHz
Memory: 11.1 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 5500

This looks similar to #342672 and #400459 but it seems to be a different bug.
Comment 1 vanyossi 2022-10-19 05:12:04 UTC
I can confirm this on master, It is clear by the backtrace that krita is waiting for sqlite database to be freed to continue. 

 thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x000000018f8fe06c libsystem_kernel.dylib`__semwait_signal + 8
    frame #1: 0x000000018f806fc8 libsystem_c.dylib`nanosleep + 220
    frame #2: 0x000000018f806ee0 libsystem_c.dylib`usleep + 68
    frame #3: 0x0000000134ba63fc libqsqlite.dylib`___lldb_unnamed_symbol442 + 60
    frame #4: 0x0000000134bb6cf4 libqsqlite.dylib`___lldb_unnamed_symbol649 + 108
    frame #5: 0x0000000134bc6d84 libqsqlite.dylib`___lldb_unnamed_symbol820 + 40
    frame #6: 0x0000000134bd6dac libqsqlite.dylib`___lldb_unnamed_symbol909 + 2448
    frame #7: 0x0000000134be8c64 libqsqlite.dylib`___lldb_unnamed_symbol941 + 55716
    frame #8: 0x0000000134ba6c2c libqsqlite.dylib`___lldb_unnamed_symbol452 + 260
    frame #9: 0x0000000134b98dc8 libqsqlite.dylib`___lldb_unnamed_symbol283 + 412
    frame #10: 0x0000000134b9a508 libqsqlite.dylib`___lldb_unnamed_symbol294 + 1456
    frame #11: 0x0000000100b82fe0 QtSql`QSqlQuery::exec(QString const&) + 844
    frame #12: 0x0000000134b9be50 libqsqlite.dylib`___lldb_unnamed_symbol317 + 116
    frame #13: 0x0000000101326f5c libkritaresources.19.dylib`KisResourceCacheDb::synchronizeStorage(storage=<unavailable>) at KisResourceCacheDb.cpp:1920:30 [opt]
    frame #14: 0x0000000101331fd4 libkritaresources.19.dylib`KisResourceLocator::synchronizeDb(this=0x0000600000238060) at KisResourceLocator.cpp:1183:14 [opt]
    frame #15: 0x00000001013305c0 libkritaresources.19.dylib`KisResourceLocator::initialize(this=0x0000600000238060, installationResourcesLocation=<unavailable>) at KisResourceLocator.cpp:129:10 [opt]
    frame #16: 0x000000010269a56c libkritaui.19.dylib`KisApplication::registerResources(this=0x000000016fdff228) at KisApplication.cpp:371:74 [opt]
    frame #17: 0x000000010269bd18 libkritaui.19.dylib`KisApplication::start(this=0x000000016fdff228, args=0x000000016fdff2b8) at KisApplication.cpp:462:10 [opt]
Comment 2 Halla Rempt 2022-10-31 15:31:58 UTC
Actually, the second krita instance should send the commands to the running process, which executes it. We cannot run two instances of Krita anymore at all.
Comment 3 lionbark 2022-11-10 13:19:25 UTC
Have been having issues with this as well; currently getting around it by using the last major version (4.4.8) to do the programmatic exporting; image seems to come out alright for me but not sure if this would work with all cases.
Comment 4 Geekley 2022-11-25 03:26:44 UTC
My main issue with this bug is that, since the call from the other app needs to be synchronous, Krita freezing freezes the waiting app as well, with no explanation to the user. :(
I'm aware having a second apt installation besides flatpak works (though yes, older version can have different results), but in any case I can't require users to have 2 Krita installations...
Comment 5 Halla Rempt 2022-11-30 16:22:14 UTC
Please don't change the version number: it's not the last version that still has the bug, but the version for which the bug was first reported.
Comment 6 Geekley 2022-11-30 19:43:10 UTC
(In reply to Halla Rempt from comment #5)
> Please don't change the version number: it's not the last version that still
> has the bug, but the version for which the bug was first reported.

Oh, OK. Sorry for the confusion.
Comment 7 Geekley 2023-02-08 07:27:32 UTC
Still happening on 5.1.5.

I also noticed that when converting from a webp file, the "opening webp" window is shown even from the command line. As I understand, this command is meant to be used in batch processing and shouldn't show any GUI. In fact this window is weird - I'd expect all files are opened in a lossless manner, and preferences apply only when saving (like with png).
I don't know if a similar thing happens on other formats that might have such "opening windows" (are there others?).
Comment 8 Halla Rempt 2023-02-09 12:36:03 UTC
If the bug is not marked as resolved, you can safely assume that it has not yet been fixed.