Bug 361331

Summary:	Reference image docker causes a crash on browsing directories with pictures
Product:	[Frameworks and Libraries] frameworks-kimageformats	Reporter:	scaylathefox
Component:	general	Assignee:	Alex Merry <alex.merry>
Status:	RESOLVED WORKSFORME
Severity:	crash	CC:	griffinvalley, halla, kdelibs-bugs-null
Priority:	NOR
Version First Reported In:	5.17.0
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description scaylathefox 2016-04-02 21:55:46 UTC

Reference image docker crashes Krita when opening a directory with pictures inside. It doesn't happen on every directory or even same one, but when I try changing directories with pictures inside them it always seems to crash within 3 to 10 directories.
Pressing "back" button might be required too, not sure on this one.
Directories with images inside seem to load longer, crash seems to happen during/after loading.
Image preview window can be shown or hidden, happens both ways.

Reproducible: Always

Steps to Reproduce:
1. Open Krita and reference image docker
2. In the docker navigate to directories that have some images stored inside them
3. Move forward and backwards between them and a crash should occur

Actual Results:  
Krita closes with a crash. A crash reporting dialog comes up, but can't seem to gather anything beyond "aborted" even with debugging symbols installed.

Expected Results:  
The selected folder should open and images inside it should load in the preview window below.

Running Krita 2.9.7 on Ubuntu 15.10, kernel 4.2.0-34-generic.
When running Krita from terminal the following is produced on crash:

(krita:16013): GLib-GIO-ERROR **: inotify read(): Bad file descriptor
Trace/breakpoint trap (core dumped)

Comment 1 wolthera 2016-04-04 12:25:30 UTC

does this still happen with the 3.0 pre-alpha portable builds for linux?(check our news posts on krita.org)

Comment 2 Halla Rempt 2016-04-04 12:30:29 UTC

I suspect that this is because a specific file in those directories that crashes qt's imageio plugins.

Comment 3 scaylathefox 2016-04-04 14:46:26 UTC

@Boudewijn Rempt
Okay so I did some more testing..

I made a couple of directories filled only with copies of a small png file and couldn't reproduce the crash. Then I made the same thing, only that I converted that png to gimp's XCF format - no crash.

Then I added a few layers to the xcf and resized it to 5000x5000 which brought the file size up to 350MB. I added 4 of those into the root of the testing directory - and the crash happened upon leaving the directory that contained the big files. Not necessarily on the first try, but on 2nd or 3rd try it did.

I then resized the file to 10000x10000 and saved it as PNG (30MB). A few directories of these gave me a freeze, but I wasn't able to reproduce a crash. I added a few 20000x20000 uncompressed PNGs to that (1.3GB each), still no crash.

So as it seems now the problem lies with big XCF files, a number of which were also in the directory in which I originally observed the crash.

@wolthera
I can't reproduce the crash on 3.0 alpha, probably because reference image docker flat out ignores XCF files and doesn't even show them as files.

Comment 4 Halla Rempt 2016-04-05 10:47:17 UTC

Sounds like a problem with the xcf qimageio plugin :-( It's part of the kimageformats framework. I actually thought that we did package them with 3.0, that's something to check.

Comment 5 Justin Zobel 2020-12-17 05:23:02 UTC

Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Comment 6 scaylathefox 2020-12-18 00:07:42 UTC

Hello,

reference image docker has since been removed from Krita, so this bug report is likely no longer relevant. I tried the steps I described back then with the regular file open dialog just in case, and ran into no issues. As such, I believe this issue is resolved.