| Summary: | Crashes on opening corrupted jpg file | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Elric T <elric.templin> |
| Component: | File formats | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | halla |
| Priority: | NOR | Keywords: | drkonqi |
| Version First Reported In: | 2.9.11 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/krita/5c4c327ad429def4eaccc8d7bbd8f70d374a51ae | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: | the jpeg | ||
|
Description
Elric T
2016-04-14 02:07:20 UTC
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 |