Hi,

Can you attach the jpeg file? The crash happens inside the jpeg library: which one exactly is installed on manjaro?

Created attachment 98395 [details]
the jpeg

Since manjaro is bleeding edge i would think a rather new one :D.
Let me ask in the irc will update then.

pacman -Si openjpeg
Repository      : extra
Name            : openjpeg
Version         : 1.5.2-1
Description     : An open source JPEG 2000 codec
Architecture    : x86_64
URL             : http://www.openjpeg.org
Licenses        : BSD
Groups          : None
Provides        : None
Depends On      : zlib
Optional Deps   : lcms2: j2k_to_image and image_to_j2k programs
                  libpng: j2k_to_image and image_to_j2k programs
Conflicts With  : None
Replaces        : None
Download Size   : 134.84 KiB
Installed Size  : 419.00 KiB
Packager        : Jan de Groot <jgc@archlinux.org>
Build Date      : Mon 28 Apr 2014 09:43:52 AM CEST
Validated By    : MD5 Sum  SHA-256 Sum  Signature

Ah, that's openjpeg, which is, confusingly, not a jpeg library, but a library for loading jp2 images.

O sry.
Now i think if got them(hopefully :D):

pacman -Si libjpeg-turbo
Repository      : extra
Name            : libjpeg-turbo
Version         : 1.4.2-2
Description     : JPEG image codec with accelerated baseline compression and
                  decompression
Architecture    : x86_64
URL             : http://libjpeg-turbo.virtualgl.org/
Licenses        : custom
Groups          : None
Provides        : libjpeg=8.0.2  turbojpeg
Depends On      : None
Optional Deps   : None
Conflicts With  : libjpeg  turbojpeg
Replaces        : libjpeg  turbojpeg
Download Size   : 346.95 KiB
Installed Size  : 1454.00 KiB
Packager        : Gaetan Bisson <bisson@archlinux.org>
Build Date      : Sat 05 Dec 2015 10:50:55 PM CET
Validated By    : MD5 Sum  SHA-256 Sum  Signature

Or Maybe its:

pacman -Si lib32-libjpeg-turbo
Repository      : multilib
Name            : lib32-libjpeg-turbo
Version         : 1.4.2-1
Description     : libjpeg derivative with accelerated baseline JPEG compression
                  and decompression (32-bit)
Architecture    : x86_64
URL             : http://libjpeg-turbo.virtualgl.org/
Licenses        : custom
Groups          : None
Provides        : lib32-libjpeg=8.0.2  lib32-turbojpeg
Depends On      : lib32-glibc  libjpeg-turbo
Optional Deps   : None
Conflicts With  : lib32-libjpeg  lib32-turbojpeg
Replaces        : lib32-libjpeg  lib32-turbojpeg
Download Size   : 120.61 KiB
Installed Size  : 644.00 KiB
Packager        : Felix Yan <felixonmars@archlinux.org>
Build Date      : Thu 08 Oct 2015 03:47:31 PM CEST
Validated By    : MD5 Sum  SHA-256 Sum  Signature


Greetings.
If it isnt one of those, then iv got to have a talk with the guys in the IRC again :D.

Yes, that's the right one :-)

Hm, the trick is going to be to teach libjpeg to not crash on a broken file...

That sounds like a plan :D. Is there any way to recover this file? Will there be an "upstream" (is that the right name?), bugfix? I think its strange that the developer, never thought. "Hey maybe i should catch broken file exceptions".

Git commit 5c4c327ad429def4eaccc8d7bbd8f70d374a51ae by Boudewijn Rempt.
Committed on 14/04/2016 at 11:51.
Pushed by rempt into branch 'master'.

M  +273  -255  plugins/impex/jpeg/kis_jpeg_converter.cc

http://commits.kde.org/krita/5c4c327ad429def4eaccc8d7bbd8f70d374a51ae

To recover the file, you need specialized tools, I'm afraid.  The jpeg library says:

Corrupt JPEG data: 5 extraneous bytes before marker 0xd5
JPEG datastream contains no image

So the image is well and truly hosed. But I just added an error handler, and yes, it's weird we never did that before! This plugin is eleven years old...

Thank you very much :).

Git commit 9b7b48f4da5655035497be17e516b4a826f8b54e by L. E. Segovia.
Committed on 18/01/2023 at 02:42.
Pushed by lsegovia into branch 'master'.

global: Fix ECM exception handling semantics mismatch in MSVC

According to the Extra CMake Modules documentation [1],

> kde_enable_exceptions()
>
> Enables exceptions for C++ source files compiled for the CMakeLists.txt
> file in the current directory and all subdirectories.

What isn't listed there, however, is that exceptions are enabled through
the usage of -fexceptions (GCC/Clang) and -EHsc (MSVC/Intel) [2]. All
good... except that those mean slightly different things:

> -fexceptions
>
>    Enable exception handling. Generates extra code needed to propagate
>    exceptions. For some targets, this implies GCC generates frame
>    unwind information for all functions, which can produce significant
>    data size overhead, although it does not affect execution. If you do
>    not specify this option, GCC enables it by default for languages
>    like C++ that normally require exception handling, and disables it
>    for languages like C that do not normally require it. However, you
>    may need to enable this option when compiling C code that needs to
>    interoperate properly with exception handlers written in C++. You
>    may also wish to disable this option if you are compiling older C++
>    programs that don’t use exception handling.

(source: [3])

> c
> When used with /EHs, the compiler assumes that functions declared as
> extern "C" never throw a C++ exception. It has no effect when used with
> /EHa (that is, /EHca is equivalent to /EHa). /EHc is ignored if /EHs or
> /EHa aren't specified.

(source: [4])

These two put together mean that any exception thrown in a callstack
with C code in between works in Unix-y compilers, while they would
crash straight to Qt/QtConcurrent's event loop in MSVC.

The only affected piece of code is the JPEG error catcher,
introduced by Halla in 5c4c327ad429def4eaccc8d7bbd8f70d374a51ae, so
I added a file-level workaround there. A Krita-wide workaround is not
possible at the moment; all consumers of kritapigment would need the
same surgical workaround, because OpenEXR also injects /EHsc through
its exported targets. This was already reported upstream [5].

[1]: https://api.kde.org/ecm/kde-module/KDECompilerSettings.html
[2]: https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/v5.101.0/kde-modules/KDECompilerSettings.cmake#L502-526
[3]: https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Code-Gen-Options.html#index-fexceptions
[4]: https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model?view=msvc-170#arguments
[5]: https://github.com/AcademySoftwareFoundation/openexr/issues/1326
CCMAIL: kimageshop@kde.org

M  +4    -0    CMakeLists.txt
M  +7    -0    plugins/impex/jpeg/CMakeLists.txt

https://invent.kde.org/graphics/krita/commit/9b7b48f4da5655035497be17e516b4a826f8b54e