Bug 310202 - gwenview crash when closing the program
Summary: gwenview crash when closing the program
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: gwenview
Classification: Applications
Component: general (show other bugs)
Version: 2.10.0
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Gwenview Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-16 12:46 UTC by Simon Andric
Modified: 2013-06-23 20:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
New crash information added by DrKonqi (4.87 KB, text/plain)
2012-11-25 20:44 UTC, Jaak Ristioja
Details
Gwenview 4.9.4 valgrind output (18.14 KB, application/octet-stream)
2012-12-09 17:12 UTC, Jaak Ristioja
Details
New crash information added by DrKonqi (4.76 KB, text/plain)
2012-12-16 07:20 UTC, Oldřich Jedlička
Details
New crash information added by DrKonqi (4.73 KB, text/plain)
2012-12-22 15:51 UTC, Oldřich Jedlička
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Andric 2012-11-16 12:46:29 UTC
Application: gwenview (2.10.0)
KDE Platform Version: 4.9.80
Qt Version: 4.8.4
Operating System: Linux 3.7.0-0-generic i686
Distribution: Ubuntu Raring Ringtail (development branch)

-- Information about the crash:
- What I was doing when the application crashed:

gwenview crashed when i closed it. Last folder i was viewing files (pictures) from was from my external hard drive which is connected to computer via ethernet cable (wd mybook).

thank you

nicce day

Simon

The crash can be reproduced every time.

-- Backtrace:
Application: Gwenview (gwenview), signal: Aborted
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0xb3e3a740 (LWP 10182))]

Thread 2 (Thread 0xb2767b40 (LWP 10204)):
#0  0xb6f19df3 in __GI___pthread_mutex_lock (mutex=0xb1e00558) at pthread_mutex_lock.c:95
#1  0xb4a70510 in g_mutex_lock () from /lib/i386-linux-gnu/libglib-2.0.so.0
#2  0xb4a2ee45 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#3  0xb4a2f0d1 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0
#4  0xb7137366 in QEventDispatcherGlib::processEvents (this=0xb1e00468, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#5  0xb70fca4d in QEventLoop::processEvents (this=0xb2767248, flags=...) at kernel/qeventloop.cpp:149
#6  0xb70fcbc5 in QEventLoop::exec (this=0xb2767248, flags=...) at kernel/qeventloop.cpp:204
#7  0xb6fd63cb in QThread::exec (this=0x89b3ba0) at thread/qthread.cpp:542
#8  0xb70da2c2 in QInotifyFileSystemWatcherEngine::run (this=0x89b3ba0) at io/qfilesystemwatcher_inotify.cpp:256
#9  0xb6fd8cd5 in QThreadPrivate::start (arg=0x89b3ba0) at thread/qthread_unix.cpp:338
#10 0xb6f17d88 in start_thread (arg=0xb2767b40) at pthread_create.c:311
#11 0xb575e0be in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:132

Thread 1 (Thread 0xb3e3a740 (LWP 10182)):
[KCrash Handler]
#7  0xb77da424 in __kernel_vsyscall ()
#8  0xb569e92f in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
#9  0xb56a1ec3 in __GI_abort () at abort.c:90
#10 0xb6fcc1e1 in qt_message_output (msgType=QtFatalMsg, buf=0x8a86800 "ASSERT: \"qMetaTypeGuiHelper\" in file kernel/qmetatype.cpp, line 1384") at global/qglobal.cpp:2323
#11 0xb6fcc389 in qt_message (msgType=QtFatalMsg, msg=0xb717a514 "ASSERT: \"%s\" in file %s, line %d", ap=0xbfadbd74 "H\302\037\267r\271\037\267h\005") at global/qglobal.cpp:2369
#12 0xb6fcc81f in qFatal (msg=0xb717a514 "ASSERT: \"%s\" in file %s, line %d") at global/qglobal.cpp:2552
#13 0xb6fcbd8e in qt_assert (assertion=0xb71fc248 "qMetaTypeGuiHelper", file=0xb71fb972 "kernel/qmetatype.cpp", line=1384) at global/qglobal.cpp:2018
#14 0xb710ee2c in QMetaType::destroy (type=70, data=0x90f5bc8) at kernel/qmetatype.cpp:1384
#15 0xb7115718 in QMetaCallEvent::~QMetaCallEvent (this=0x8a4c930, __in_chrg=<optimized out>) at kernel/qobject.cpp:508
#16 0xb71157c7 in QMetaCallEvent::~QMetaCallEvent (this=0x8a4c930, __in_chrg=<optimized out>) at kernel/qobject.cpp:517
#17 0xb70fe354 in QCoreApplicationPrivate::~QCoreApplicationPrivate (this=0x8844df8, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:480
#18 0xb5d93267 in QApplicationPrivate::~QApplicationPrivate (this=0x8844df8, __in_chrg=<optimized out>) at kernel/qapplication.cpp:222
#19 0xb5d93383 in QApplicationPrivate::~QApplicationPrivate (this=0x8844df8, __in_chrg=<optimized out>) at kernel/qapplication.cpp:226
#20 0xb70c2ef7 in QScopedPointerDeleter<QObjectData>::cleanup (pointer=0x8844df8) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:62
#21 0xb711dd77 in QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer (this=0xbfadc014, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:100
#22 0xb7116394 in QObject::~QObject (this=0xbfadc010, __in_chrg=<optimized out>) at kernel/qobject.cpp:816
#23 0xb70ff215 in QCoreApplication::~QCoreApplication (this=0xbfadc010, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:830
#24 0xb5d95309 in QApplication::~QApplication (this=0xbfadc010, __in_chrg=<optimized out>) at kernel/qapplication.cpp:1098
#25 0xb6b043f5 in KApplication::~KApplication (this=0xbfadc010, __in_chrg=<optimized out>) at /build/buildd/project-neon-kdelibs-2+git20121115+r92187/kdeui/kernel/kapplication.cpp:894
#26 0x0808b922 in main (argc=5, argv=0xbfadc0e4) at /build/buildd/project-neon-gwenview-2+git20121115+r2821/app/main.cpp:142

This bug may be a duplicate of or related to bug 298006.

Possible duplicates by query: bug 309061, bug 307621, bug 302243, bug 298008, bug 298006.

Reported using DrKonqi
Comment 1 Jaak Ristioja 2012-11-25 20:44:48 UTC
Created attachment 75478 [details]
New crash information added by DrKonqi

gwenview (2.9.2) on KDE Platform 4.9.3 using Qt 4.8.2

- What I was doing when the application crashed:

I have a slideshow set on my KDE desktop. I clicked "Open Wallpaper Image" from the desktop popup menu, which opened gwenview with the active wallpaper image from the slideshow. If I closed gwenview, this crash happened.

This crash only appears to occur when Gwenview is in image view mode, not in folder browsing mode.

-- Backtrace (Reduced):
#6  0x000077b34b6ebb45 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#7  0x000077b34b6ecfbb in __GI_abort () at abort.c:91
[...]
#11 0x000077b34daf55be in QMetaType::destroy (type=70, data=0x77b329c976c0) at kernel/qmetatype.cpp:1384
[...]
#14 0x000077b34daec8aa in QCoreApplicationPrivate::~QCoreApplicationPrivate (this=0x765a8dfec40, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:449
#15 0x000077b34c448b09 in QApplicationPrivate::~QApplicationPrivate (this=0x765a8dfec40, __in_chrg=<optimized out>) at kernel/qapplication.cpp:223
Comment 2 Aurelien Gateau 2012-12-07 22:17:37 UTC
Unfortunately the backtrace is not enough to understand this bug. Is it 100% 
reproducable for you? Can you try to reproduce the bug while running Gwenview 
in Valgrind, then post Valgrind output?
Comment 3 Jaak Ristioja 2012-12-09 17:12:38 UTC
Created attachment 75755 [details]
Gwenview 4.9.4 valgrind output

I'm unable to reproduce with KDE 4.9.4. However, here's the valgrind output for 4.9.4 anyways. With a weird assertion at the end.
Comment 4 Oldřich Jedlička 2012-12-16 07:20:24 UTC
Created attachment 75857 [details]
New crash information added by DrKonqi

gwenview (2.9.2) on KDE Platform 4.9.3 using Qt 4.8.3

- What I was doing when the application crashed:

I opened the gwenview from Midnight Commander as an edit action on an PNG image on local drive (`gwenview %f >/dev/null 2>&1 &`) and closed it afterwards. The program always crashes. I'm doing no navigation between images.

-- Backtrace (Reduced):
#8  0xb593093f in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
#9  0xb5932205 in __GI_abort () at abort.c:90
[...]
#13 0xb6f9d55a in qt_assert (assertion=0xb719e352 "qMetaTypeGuiHelper", file=0xb719e33d "kernel/qmetatype.cpp", line=1384) at global/qglobal.cpp:2013
#14 0xb70c79ae in QMetaType::destroy (type=70, data=0xb0204270) at kernel/qmetatype.cpp:1384
[...]
#17 0xb70be8e4 in QCoreApplicationPrivate::~QCoreApplicationPrivate (this=0x957b6c0, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:449
Comment 5 Oldřich Jedlička 2012-12-16 07:21:25 UTC
I still have 4.9.3, so maybe I can try to run it with Valgring.
Comment 6 Oldřich Jedlička 2012-12-16 07:59:28 UTC
This is not 100% reproducible. When closed too early, it doesn't crash. When closed too late, it doesn't crash. There is some operation, which isn't terminated or is terminated too late (when other parts are destroyed) during shutdown. I'm not able to catch this moment with Valgrind running.
Comment 7 Oldřich Jedlička 2012-12-22 15:51:08 UTC
Created attachment 75970 [details]
New crash information added by DrKonqi

gwenview (2.9.4) on KDE Platform 4.9.4 using Qt 4.8.4

- What I was doing when the application crashed:

Same as before - opened the image from Midnight Commander and closed easly. The problem is still there. From last time I've updated the Qt to 4.8.4 and KDE to 4.9.4.

-- Backtrace (Reduced):
#8  0xb590193f in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
#9  0xb5903205 in __GI_abort () at abort.c:90
[...]
#13 0xb6fa1015 in qt_assert (assertion=0xb71c9452 "qMetaTypeGuiHelper", file=0xb71c943d "kernel/qmetatype.cpp", line=1384) at global/qglobal.cpp:2018
#14 0xb70e362e in QMetaType::destroy (type=70, data=0x89f6738) at kernel/qmetatype.cpp:1384
[...]
#17 0xb70d9784 in QCoreApplicationPrivate::~QCoreApplicationPrivate (this=0x8496348, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:480
Comment 8 Oldřich Jedlička 2013-06-02 06:51:08 UTC
Crash (identical backtrace) still present with 4.10.3. Is there some detail in the backtrace from which you could find the problem? I can use gdb to find the detail.
Comment 9 Oldřich Jedlička 2013-06-23 20:37:12 UTC
Still present with latest gwenview.

The core dump contains two threads. One is main() and second one is QInotifyFileSystemWatcherEngine::run.

The important information from the Q_ASSERT shown in all backtraces is that the destructor of QApplication has returned and the instance destruction continued by parent class (QCoreApplication) - the qMetaTypeGuiHelper is NULL (set in ~QApplication() as the last step). The destruction continues to queued events (~QCoreApplicationPrivate destroying postEventList) and there is a GUI event (QMetaCallEvent), which needs the qMetaTypeGuiHelper in its destructor.

The gdb says that QMetaCallEvent's callFunction is Gwenview::ThumbnailCache::qt_static_metacall(QObject*, QMetaObject::Call, int, void**).

Is there anything more I can do in order to investigate the problem? This is what I got from the core dump.
Comment 10 Oldřich Jedlička 2013-06-23 20:39:06 UTC
I see the status is RESOLVED even though the crash is still here and reproducible. I there is no response, I will create a new bug report.
Comment 11 Oldřich Jedlička 2013-06-23 20:54:26 UTC
I realised there was no response to my last comment already, so I created bug 321540.