Bug 390058

Summary:	Gwenview "crashes" when opening an image from zip archive via Dolphin/KIO
Product:	[Applications] gwenview	Reporter:	Omar Plummer <omarplummer>
Component:	general	Assignee:	Gwenview Bugs <gwenview-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	crash	CC:	bugseforuns, nate, null
Priority:	NOR
Version:	Git (add output of "git log -1 --oneline" to description)
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=391580
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Omar Plummer 2018-02-08 07:47:16 UTC

This issue arises from a line of code (Q_ASSERT) inside the KIO framework, but since it appears to only affect Gwenview for me, I assumed this would be the place to report it.

Git Commit:
613dde71 (HEAD -> master, origin/master, origin/HEAD) Resize top bar in fullscreen view mode on toggling sidebar

Steps to reproduce:

1. Enable "Open archives as folder" option in Dolphin.

2. Open a zip archive containing images

3. Open an image from within the archive

4. Gwenview opens and then closes immediately

The following is written to .xsession-errors:

unknown: ASSERT: "!listersCurrentlyHolding.contains(kdl)" in file kde/src/frameworks/kio/src/core/kcoredirlister.cpp, line 2826

By commenting that line and rebuilding KIO, Gwenview is able to open (and navigate) images from within archives without crashing.

Comment 1 Omar Plummer 2018-02-08 17:40:32 UTC

I have tested opening the same images in other viewers via "right-click -> Open with...", as well as with other file types opened from other zip archives (eg. PDFs opened in Okular). So far, Gwenview is the only program that exhibits this error.

Comment 2 Patrick Silva 2018-02-20 14:26:35 UTC

cannot reproduce using gwenview 17.12.2 on Arch Linux.

Comment 3 Christoph Feck 2018-02-20 22:47:15 UTC

Arch doesn't enable asserts, so you won't see them.

Comment 4 null 2018-02-20 23:04:13 UTC

Omar: Thanks for reaching out. In general you should report issues against the component where changes should be done, but I agree it's not as clear cut in this case. I doubt we can simply remove the ASSERT in KIO, surely it was added for a reason!?

Nevertheless, I cannot reproduce with KIO master. Could you please let us know your KIO version?

Comment 5 Omar Plummer 2018-02-24 01:29:57 UTC

Hello all,

Thanks for looking at this issue.

I realise that the removal of the assert in KIO would not be a suitable fix for this, especially since Gwenview is the only application I've found so far that exhibits this bug, but I hoped that pointing it out might be helpful in narrowing down the source of the bug in Gwenview.

My current version of KIO is built from Git (commit: 4d153df7).

In fact, My entire KDE install, as well as Qt 5.9.4 are built from Git.

Please let me know if there's any other information that you think necessary that I can provide.

Comment 6 null 2018-02-24 11:42:57 UTC

Tried that KIO commit, still cannot reproduce. However, I grepped my notes for the log message, and lo and behold, found something: I get this for pretty much any network browsing in gwenview, perhaps this is not about zip files. Test case: "gwenview remote:/network" (remote:/ and network:/ on its own work fine, though).

Can you confirm you are doing something network related? If it works in other viewers, it might be that those download to /tmp first, while Gwenview uses direct access via KIO (in most apps you can check by Ctrl-O and looking at the folder the file is in).

Let me know, and then we might see whether the problem is a duplicate (search for kcoredirlister.cpp on Bugzilla) or Gwenview is wrong somewhere. Keep in mind as this only affects Debug builds, this is of low priority (we can help if you'd like to investigate the source for yourself, of course, seeing you are already on Phabricator).

---

More notes:
- Not related to ContextManager rework, because assert triggers on 17.08 too.
- Tested KIO 5.28, where the assert is also present.

Comment 7 Omar Plummer 2018-02-26 19:01:47 UTC

Henrik: You have hit the nail squarely on the head. It does in fact seem to be network-related. I completely overlooked the fact that the filesystem I was opening these images from is mounted via SSHFS. The issue disappears if I copy the archive to a local filesystem and then browse it from there.

I can also confirm that the other image editors I have tried copy the file locally to ~/.cache5/kioexec/krun/NNNN_N/ before opening (where 'NNNN_N' represents a dynamically created directory in each instance).

I can work around the issue in Gwenview by opening the archive file itself via Right-click -> Open with... -> Gwenview, and then browsing from there, but I've noticed that when I do this, if I hit Ctrl+o, Gwenview pops up an error dialog that reads "Unable to create io-slave. klauncher said: Unknown protocol '' but then opens the "Open Image" dialog to the correct location of the archive anyway. So I'm not too sure what's happening there.

Many thanks for your feedback on this, as it has been driving me crazy for quite a while.

As for looking into the code myself, I have been wanting to delve deeper into KDE coding for quite some time, but my proficiency in C++ is very weak, and I've so far been unable to find the time/opportunity to improve it significantly. However, I will continue to dig deeper as much as I'm able to. That being said; I should point out that I think the KDE community has made leaps and bounds over the last few years with regards to easing the entry process for new contributors. My thanks to all who have contributed to KDE in even the smallest way.

Comment 8 Nate Graham 2018-11-05 21:43:50 UTC

Fixed in Frameworks 5.51 with the fix for 397742.

*** This bug has been marked as a duplicate of bug 397742 ***