0.85 Linux: crash after file(s) are deleted or moved

*** Please report new bugs here! ***

Moderator: Dreamer

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

0.85 Linux: crash after file(s) are deleted or moved

Postby pangwolin » Thu Apr 20, 2017 11:29 pm

XnView: MP 0.85 and 0.86 - 64 bit
OS: Linux 64bit

Description:
XnViewMP crashes when a file is deleted (via shortcut) in the browser mode. It crashes also while in viewer mode when immediately reading the other files in working directory very quickly after a file has been deleted (using mouse wheel helps reproduce the bug).

Effect: Program crashes and quits, core dumped. Files are properly deleted/moved to trash in gvfs (no problem there).

To reproduce:
1. [Optional?] Be in viewer mode, double click to switch to browser mode.
2. Select multiple files in browser mode.
3. Press the delete shortcut key.
4. [Optional?] Immediatly click on another file in the browser file listing.
5. Crash!

Actual behaviour (bug):
While in browser mode, immediately after deleting one or more files, click on another file in the file listing, it will most certainly crash.
It seems that XnViewMP keeps some locks on the files which are being deleted and crashes or something. Could be a race condition of sorts?
Probably related to how it's trying to read ahead the next file in directory and trying to generate the thumbnail? No idea.
In view mode, using the mouse wheel to very quickly jump to the next files help crashing. It doesn't crash all the time, could be depending on the file types?

Here's the core dump from the journalctl (system) logs:
Apr 21 01:11:35 clevo XnView[32559]: qt5ct: using qt5ct plugin
Apr 21 01:11:35 clevo XnView[32559]: qt5ct: palette support is disabled
Apr 21 01:11:35 clevo XnView[32559]: qt5ct: custom style sheet is disabled
Apr 21 01:11:35 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:11:35 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:11:35 clevo XnView[32559]: QObject::connect: No such slot AbstractViewWindow::onPagePrevious()
Apr 21 01:11:35 clevo XnView[32559]: QObject::connect: No such slot AbstractViewWindow::onPageNext()
Apr 21 01:11:35 clevo XnView[32559]: QObject::connect: No such slot AbstractViewWindow::onPageFirst()
Apr 21 01:11:35 clevo XnView[32559]: QObject::connect: No such slot AbstractViewWindow::onPageLast()
Apr 21 01:11:35 clevo XnView[32559]: QObject::connect: No such slot AbstractViewWindow::onNormalize2()
Apr 21 01:11:35 clevo XnView[32559]: QObject::connect: No such slot AbstractViewWindow::onAlign()
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:15:58 clevo XnView[32559]: libpng warning: iCCP: known incorrect sRGB profile
Apr 21 01:16:04 clevo kernel: traps: ThumbLoaderThre[32569] general protection ip:7f0b97f7d11b sp:7f0b824ed1f0 error:0
Apr 21 01:16:04 clevo kernel: in libQt5Core.so.5.8.0[7f0b97dce000+4cc000]
Apr 21 01:16:04 clevo systemd[1]: Started Process Core Dump (PID 2325/UID 0).
Apr 21 01:16:05 clevo systemd-coredump[2326]: Process 32559 (XnView) of user 1000 dumped core.

Stack trace of thread 32569:
#0 0x00007f0b97f7d11b _ZNK9QFileInfo4pathEv (libQt5Core.so.5)
#1 0x0000000000711106 n/a (XnView)
#2 0x000000000082ff5a n/a (XnView)
#3 0x000000000083100f n/a (XnView)
#4 0x00007f0b97e7b6d8 n/a (libQt5Core.so.5)
#5 0x00007f0b97bb72e7 start_thread (libpthread.so.0)
#6 0x00007f0b962f754f __clone (libc.so.6)

Stack trace of thread 32565:
#0 0x00007f0b962ed67d poll (libc.so.6)
#1 0x00007f0b90d9c8e0 n/a (libxcb.so.1)
#2 0x00007f0b90d9e679 xcb_wait_for_event (libxcb.so.1)
#3 0x00007f0b87833239 n/a (libQt5XcbQpa.so.5)
#4 0x00007f0b97e7b6d8 n/a (libQt5Core.so.5)
#5 0x00007f0b97bb72e7 start_thread (libpthread.so.0)
#6 0x00007f0b962f754f __clone (libc.so.6)

Stack trace of thread 32559:
#0 0x00007f0b96305d2b __fprintf_chk (libc.so.6)
#1 0x0000000000710eed n/a (XnView)
#2 0x0000000000828cd8 n/a (XnView)
#3 0x00007f0b98082ba9 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5)
#4 0x00007f0b990c334c _ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5)
#5 0x00007f0b990cab61 _ZN12QApplication6notifyEP7QObjectP6QEvent (libQt5Widgets.so.5)
#6 0x00007f0b98056440 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5)
#7 0x00007f0b98058bcd _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5)
#8 0x00007f0b980aac43 n/a (libQt5Core.so.5)
#9 0x00007f0b938685a7 g_main_context_dispatch (libglib-2.0.so.0)
#10 0x00007f0b93868810 n/a (libglib-2.0.so.0)
#11 0x00007f0b938688bc g_main_context_iteration (libglib-2.0.so.0)
#12 0x00007f0b980ab04f _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)



Expected behaviour: files is deleted, next file is read but XnView doesn't crash.

Note: this has happened to me since 0.82, this bug has been around for a long time, but it's much more frequent and consistent since 0.85.
Last edited by pangwolin on Fri Apr 28, 2017 11:36 pm, edited 6 times in total.

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

Re: 0.85 Linux: crash after file(s) are deleted

Postby pangwolin » Fri Apr 21, 2017 12:23 am

I just deleted 46 files that way, P115.jpg to P160.jpg from a directory called /diskB/2016-04/No.13/ and it crashed.

I used strace to inspect what happened, attached is the end of the log around the part where I was dealing with these files.
Also attached the corresponding syslog for that particular crash as well.
Better use an strace highlight syntax to inspect that (there is a decent one for Sublime Text 3 for example).

I hope it helps.
Attachments
xnviewmp_170421b_sylog.log.zip
(2.14 KiB) Downloaded 1 time
xnviewmp_170421b_cut.strace.zip
(289.79 KiB) Downloaded 1 time

User avatar
helmut
Posts: 8116
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Re: 0.85 Linux: crash after file(s) are deleted

Postby helmut » Fri Apr 21, 2017 7:00 am

Thank you very much, pangwolin, for the detailed bug report and the log and trace files. This will help Pierre to track down and solve the problem.

Depending on frequency and probability of the problem (crash) this should handled as a must fix for the next release.
Are your PNG files normal or rather special? Does the problem occur on some or on most PNG files?

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

Re: 0.85 Linux: crash after file(s) are deleted

Postby pangwolin » Wed Apr 26, 2017 9:28 pm

The crash happens with any file really. Tested with PNG and JPG files, both colors, greyscale, various sizes.

Edit: I should also point out that if I wait a few seconds after deleting files in browser mode, and only THEN click on another file in the list, it doesn't crash.

User avatar
xnview
Author of XnView
Posts: 27082
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.85 Linux: crash after file(s) are deleted

Postby xnview » Fri Apr 28, 2017 7:26 am

is it possible to have your xnview.ini, i can't reproduce
Pierre.

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

Re: 0.85 Linux: crash after file(s) are deleted

Postby pangwolin » Fri Apr 28, 2017 3:44 pm

Sure thing, here attached is my xnview.ini file.

I just tested moving a directory with files in them through the browser mode, and it crashed too. So it's definitely trigger by moving files around (since files are moved to trash when deleted too). The files are properly moved though, it's probably related to how the browser has to update the view?
Also, if I rename a directory in browser mode, xnview can't access that directory to display its content anymore.

Here's the end part of my stdout: https://pastebin.com/raw/6Wvwac0u
What's with all these IDAT lines anyway? Could it be the cause of a buffer overflow or something? (I have no idea what I'm talking about).

Thanks for looking into that anyway. Much appreciated.

EDIT: oh I have to point out just in case: I'm using my system libraries because without that, xnview fails to start on my system and says:
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "/opt/xnviewmp/lib/platforms".
Available platform plugins are: eglfs (from /opt/xnviewmp/lib/platforms), linuxfb (from /opt/xnviewmp/lib/platforms), minimal (from /opt/xnviewmp/lib/platforms), minimalegl (from /opt/xnviewmp/lib/platforms), offscreen (from /opt/xnviewmp/lib/platforms), xcb (from /opt/xnviewmp/lib/platforms).

So my xnview.sh points to /usr/lib like this:

Code: Select all

#!/bin/sh
dirname=`readlink -e "$0"`
dirname=`dirname "$dirname"`
export LD_LIBRARY_PATH="/usr/lib:$dirname/Plugins"
export QT_PLUGIN_PATH="/usr/lib"
export QT_QPA_PLATFORM_PLUGIN_PATH="$dirname/lib/platforms"
QT_QPA_PLATFORMTHEME=qt5ct
exec "$dirname/XnView" "$@"


and qt.conf is like this:

Code: Select all

[Paths]
Plugins = Plugins
lib = lib
Attachments
xnview.ini.zip
(7.55 KiB) Downloaded 2 times

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

Re: 0.85 Linux: crash after file(s) are deleted

Postby pangwolin » Fri Apr 28, 2017 4:53 pm

OK, I guess it's just a library version mismatch somewhere. My system libs must be more up to date than the ones shipped with xnview.

Back to square one then. If I use the bundled libs, I have the font glitch.

EDIT: ok nevermind, it seems it doesn't crash anymore since 0.86 rel1.

EDIT2: nevermind again, it's still crashing. Selecting and deleting multiple files triggers the crash.
Last edited by pangwolin on Mon May 01, 2017 11:59 pm, edited 1 time in total.

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

Re: 0.85 Linux: crash after file(s) are deleted or moved

Postby pangwolin » Mon May 01, 2017 11:54 pm

Good news, I've found a more reliable way to reproduce the crash:
You have to keep at least one of the soon-to-be-moved (or deleted) files opened in view mode while moving (or deleting) files in browser mode.

Deleting just one file, while it's still opened in view mode doesn't crash though.
Only when multiple files get moved/deleted (including the file opened in view mode) does it crash.

Note: in view mode, if I go back to a file that is about to be deleted (as I already pressed the delete button on ~20+ files and it's still catching up), it will crash.

User avatar
xnview
Author of XnView
Posts: 27082
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.85 Linux: crash after file(s) are deleted or moved

Postby xnview » Tue May 02, 2017 2:34 pm

in a folder, you have 20 files, you open one of them in edit mode, and in browser mode you delete all files, right?
Pierre.

User avatar
pangwolin
Posts: 35
Joined: Sun Sep 25, 2016 7:53 pm

Re: 0.85 Linux: crash after file(s) are deleted or moved

Postby pangwolin » Wed May 03, 2017 12:08 am

Yes pretty much.

Althouth I've tested some more today and a file being opened in viewer mode doesn't have to be in the delete queue after all:
Let's say I have files names file01 to file20.
I'm in edit mode for file20.
In browser mode, I delete file01 up to file19.
Xnview will crash. even though file20 has not been sent to trash.
I think xnview is trying to get some data from the next file in the list (file20 here) and fails somewhere in the process.

Edit: deleting the files from the file manager while XnViewMP is running also crashes it. It doesn't have to be in Browser mode either, simply having a file opened, then moving a previous file in the directory crashes.
So it's not the process of deleting files which is the issue, rather the updating of the file listing or something.
The system logs seem to point to libQt5Core.so.5 a lot.


Return to “New”

Who is online

Users browsing this forum: No registered users and 1 guest