| Summary: | Dolphin Crash while selection program to open file [ QMutexLocker QThreadPrivate::finish ] | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | Leon Maurer <leon.maurer> |
| Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | aria, auxsvr, bkukushkin, brain, cfeck, heitor.adao, thomasbelvin |
| Priority: | NOR | ||
| Version: | 2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
New crash information added by DrKonqi
New crash information added by DrKonqi New crash information added by DrKonqi New crash information added by DrKonqi |
||
|
Description
Leon Maurer
2012-08-15 22:42:29 UTC
Thanks for the bug report!
> #0 0x00007fa51b6cb0bd in read () at ../sysdeps/unix/syscall-template.S:82
> #1 0x00007fa50b4d40bc in ?? () from /usr/lib/nvidia-current/libGL.so.1
> #2 0x00007fa50a531b27 in ?? () from
> /usr/lib/nvidia-current/tls/libnvidia-tls.so.295.40
Looks like a graphics driver bug to me.
Frank, the crash is in thread 2, involving mutexes. Looks more like Soprano stuff (or does Dolphin itself use threads?) Thanks Christoph! Dolphin itself only uses mutexes in the version control observer (just grepped the sources to check that). How can one actually tell in which thread the crash happens? Another thing that looks a bit strange to me is that the backtraces of all threads contain an nvidia driver frame. But that might be due to me not being an expert for crashes that involve multithreading ;-) > How can one actually tell in which thread the crash happens? Check which thread starts with [KCrash Handler]. > Dolphin itself only uses mutexes in the version control observer Since mutexes are also used by QThread itself, you should check of threads, not mutexes specifically. So the question remains, what, if any, threads does Dolphin create? > threads contain an nvidia driver frame Let's assume it is unimportant. NVIDIA libraries just hook into "start_thread" to make their GL libraries thread-safe. *** Bug 296747 has been marked as a duplicate of this bug. *** (In reply to comment #4) > Check which thread starts with [KCrash Handler]. I see, thanks! Stupid me ;-) > > Dolphin itself only uses mutexes in the version control observer > > Since mutexes are also used by QThread itself, you should check of threads, > not mutexes specifically. So the question remains, what, if any, threads > does Dolphin create? Dolphin creates threads only for the version control observer and for reading file meta data, unless I'm overlooking some other kdelibs class that indirectly starts threads. So it could indeed be related to Soprano, but I'm afraid that the backtrace contains too little information, so we need a way to reproduce the crash reliably. Resetting assignee to default as per bug #305719 *** Bug 308162 has been marked as a duplicate of this bug. *** Created attachment 77666 [details]
New crash information added by DrKonqi
dolphin (2.1) on KDE Platform 4.9.5 using Qt 4.8.3
- What I was doing when the application crashed:
Just opened Dolphin,
clicked in a bookmark to apen a directory,
right click on a file, "Open With..."
typed "kate" inside the combobox, <enter>, and dolphin crashed
-- Backtrace (Reduced):
#6 lockInline (this=0x88) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:187
#7 QMutexLocker (m=0x88, this=0x7f2248c2edf0) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:109
#8 QThreadPrivate::finish (arg=arg@entry=0x26c57b0) at thread/qthread_unix.cpp:350
#9 0x00007f2261e6bb02 in ~__pthread_cleanup_class (this=<synthetic pointer>, __in_chrg=<optimized out>) at /usr/include/pthread.h:545
#10 QThreadPrivate::start (arg=0x26c57b0) at thread/qthread_unix.cpp:340
Created attachment 78394 [details]
New crash information added by DrKonqi
dolphin (2.0) on KDE Platform 4.8.5 (4.8.5) using Qt 4.8.1
I clicked a binary file with .cfg extension to be open, entered "kate" into the application selection pop-up window, pressed enter and then Dolphin crashed.
-- Backtrace (Reduced):
#7 lockInline (this=0x4c) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:187
#8 QMutexLocker (m=0x4c, this=0xab55929c) at ../../include/QtCore/../../src/corelib/thread/qmutex.h:109
#9 QThreadPrivate::finish (arg=0xa11f108) at thread/qthread_unix.cpp:310
#10 0xb633fde8 in ~__pthread_cleanup_class (this=<synthetic pointer>, __in_chrg=<optimized out>) at /usr/include/pthread.h:545
#11 ~__pthread_cleanup_class (this=<synthetic pointer>, __in_chrg=<optimized out>) at thread/qthread_unix.cpp:716
I don't see any reports of this crash after KDE 4.9.5. On the other hand, there is a threading-related fix in Dolphin 2.2 (KDE 4.10), see bug 302264. This makes me think that the crash in the present report is related to the fixed one. Please reopen if you see this crash again in KDE 4.10.2 or later. Thanks! Created attachment 81002 [details]
New crash information added by DrKonqi
dolphin (4.10.90) on KDE Platform 4.10.90 using Qt 4.8.4
- What I was doing when the application crashed:
I tried to open a file with Open with... Kwrite. It always crashes, either before or after kwrite is launched.
-- Backtrace (Reduced):
#6 lockInline (this=0x4c) at ../../src/corelib/thread/qmutex.h:187
#7 QMutexLocker (m=0x4c, this=0xade8227c) at ../../src/corelib/thread/qmutex.h:109
#8 QThreadPrivate::finish (arg=0x995eab8) at thread/qthread_unix.cpp:350
#9 0xb6c98f8e in ~__pthread_cleanup_class (this=<optimized out>, __in_chrg=<optimized out>) at /usr/include/pthread.h:552
#10 QThreadPrivate::start (arg=0x995eab8) at thread/qthread_unix.cpp:340
(In reply to comment #12) > I tried to open a file with Open with... Kwrite. It always crashes, either > before or after kwrite is launched. Thanks for reporting. Do you use one of the version control plugins? The package dolphin-plugins is installed and the file I'm opening is a plain-text .ini file. Thanks for the update. I've tried to reproduce this with enabled git plugin, both in version-controlled and other folders, but I can't get it to crash. Could you please try if disabling all version control plugins in the "Services" section of the settings helps, and then open a new bug report? I'm not sure if the root cause is really the same as for the original report here (note that the crash has not been reported a single time for KDE 4.10.x, and I know that the version control code has changed between 4.9 -> 4.10 and again for 4.10 -> 4.11). Thanks for your help. This is weird. There was an SVN service enabled, after disabling it dolphin no longer crashes. The weird part is that after enabling it, the crashes, which were 100% reproducible, cannot be reproduced! Could this be related to some setting set to incompatible value when upgrading KDE? (In reply to comment #16) > This is weird. There was an SVN service enabled, after disabling it dolphin > no longer crashes. The weird part is that after enabling it, the crashes, > which were 100% reproducible, cannot be reproduced! Could this be related to > some setting set to incompatible value when upgrading KDE? I'm not sure. In any case, please file a new bug report if you ever see this issue again. Thanks. Created attachment 81254 [details]
New crash information added by DrKonqi
dolphin (2.2) on KDE Platform 4.10.5 using Qt 4.8.5
I had this bug on KDE 4.10.5 (Arch Linux).
– What I was doing when the application crashed:
Right clic → Open With → I write «Kate» and then hit enter. I was able to reproduce it many times, and then It stop crashing and I don’t know why.
I got many segfault but one time I obtain this backtrace. Hope it will be useful.
-- Backtrace (Reduced):
#6 0x00007fd7da51db85 in _XEventsQueued () from /usr/lib/libX11.so.6
#7 0x00007fd7da50fc9b in XEventsQueued () from /usr/lib/libX11.so.6
[...]
#12 0x00007fd7d9cd3b85 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
[...]
#14 0x00007fd7d9ca5b5f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#15 0x00007fd7d9ca5e55 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
|