Bug 306167

Summary: Cryptsetup crashes Dolphin on Closing of Loop Device
Product: dolphin Reporter: Peter Gückel <pgueckel>
Component: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: RESOLVED FIXED    
Severity: crash CC: kevin.kofler, mbriza, rdieter
Priority: NOR    
Version: 2.1   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In: 4.9.2
Attachments: valgrind as me
valgrind with sudo
new valgrind log run as me
new valgrind log run with sudo
the one and only true valgrind log file to date, no more sudo

Description Peter Gückel 2012-09-02 18:08:11 UTC
Application: dolphin (2.1)
KDE Platform Version: 4.9.00
Qt Version: 4.8.2
Operating System: Linux 3.5.3-1.fc17.x86_64 x86_64
Distribution (Platform): Fedora RPMs

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

I had had a luks-encrypted loopback file mounted and opened. When I went to close it, although I was using konsole to enter the commands, Dolphin, which was also opened, crashed. his happens every time, but only with luks-encrypted loop devices, never with dm-crypt-encrypted loop devices.

I use Rex Dieter's kde-redhat (kdeforge) repository.

The crash can be reproduced every time.

-- Backtrace:
Application: Dolphin (dolphin), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fea6e831880 (LWP 13797))]

Thread 2 (Thread 0x7fea62adb700 (LWP 13800)):
#0  0x00000032d620aa76 in __pthread_mutex_unlock_usercnt () from /lib64/libpthread.so.0
#1  0x00000032d8e83731 in g_mutex_unlock () from /lib64/libglib-2.0.so.0
#2  0x00000032d8e47195 in g_main_context_prepare () from /lib64/libglib-2.0.so.0
#3  0x00000032d8e4788b in ?? () from /lib64/libglib-2.0.so.0
#4  0x00000032d8e47a84 in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#5  0x00000032e07a4506 in QEventDispatcherGlib::processEvents (this=0x7fea5c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426
#6  0x00000032e077513f in QEventLoop::processEvents (this=this@entry=0x7fea62adacf0, flags=...) at kernel/qeventloop.cpp:149
#7  0x00000032e07753c8 in QEventLoop::exec (this=0x7fea62adacf0, flags=...) at kernel/qeventloop.cpp:204
#8  0x00000032e0678650 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501
#9  0x00000032e0755b4f in QInotifyFileSystemWatcherEngine::run (this=0x22075b0) at io/qfilesystemwatcher_inotify.cpp:248
#10 0x00000032e067b5eb in QThreadPrivate::start (arg=0x22075b0) at thread/qthread_unix.cpp:307
#11 0x00000032d6207d14 in start_thread () from /lib64/libpthread.so.0
#12 0x00000032d5af167d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7fea6e831880 (LWP 13797)):
[KCrash Handler]
#5  QString (other=<error reading variable: Cannot access memory at address 0x10>, this=0x7fff233c4cb0) at ../../src/corelib/tools/qstring.h:725
#6  QStaticText::text (this=0x10) at text/qstatictext.cpp:297
#7  0x00000032e311ca1f in QPainter::drawStaticText (this=0x7fff233c5f40, topLeftPosition=..., staticText=...) at painting/qpainter.cpp:5995
#8  0x00007fea70e65d64 in KStandardItemListWidget::paint (this=0x289c140, painter=0x7fff233c5f40, option=<optimized out>, widget=<optimized out>) at /usr/src/debug/kde-baseapps-4.9.0/dolphin/src/kitemviews/kstandarditemlistwidget.cpp:266
#9  0x00000032e35a8969 in _q_paintItem (item=item@entry=0x289c150, painter=painter@entry=0x7fff233c5f40, option=option@entry=0x2624a18, widget=widget@entry=0x263ad80, useWindowOpacity=useWindowOpacity@entry=true, painterStateProtection=painterStateProtection@entry=true) at graphicsview/qgraphicsscene.cpp:4335
#10 0x00000032e35bb455 in QGraphicsScenePrivate::drawItemHelper (this=this@entry=0x26247f0, item=item@entry=0x289c150, painter=painter@entry=0x7fff233c5f40, option=option@entry=0x2624a18, widget=widget@entry=0x263ad80, painterStateProtection=true) at graphicsview/qgraphicsscene.cpp:4431
#11 0x00000032e35bdda8 in QGraphicsScenePrivate::draw (this=this@entry=0x26247f0, item=item@entry=0x289c150, painter=painter@entry=0x7fff233c5f40, viewTransform=viewTransform@entry=0x0, transformPtr=transformPtr@entry=0x289c420, exposedRegion=exposedRegion@entry=0x26253c8, widget=0x263ad80, opacity=opacity@entry=1, effectTransform=effectTransform@entry=0x0, wasDirtyParentSceneTransform=wasDirtyParentSceneTransform@entry=false, drawItem=true) at graphicsview/qgraphicsscene.cpp:4966
#12 0x00000032e35be465 in QGraphicsScenePrivate::drawSubtreeRecursive (this=0x26247f0, item=0x289c150, painter=0x7fff233c5f40, viewTransform=0x0, exposedRegion=0x26253c8, widget=0x263ad80, parentOpacity=<optimized out>, effectTransform=0x0) at graphicsview/qgraphicsscene.cpp:4857
#13 0x00000032e35bd9da in QGraphicsScenePrivate::draw (this=this@entry=0x26247f0, item=item@entry=0x261fe80, painter=painter@entry=0x7fff233c5f40, viewTransform=viewTransform@entry=0x0, transformPtr=transformPtr@entry=0x26209f0, exposedRegion=exposedRegion@entry=0x26253c8, widget=0x263ad80, opacity=opacity@entry=1, effectTransform=effectTransform@entry=0x0, wasDirtyParentSceneTransform=wasDirtyParentSceneTransform@entry=false, drawItem=true) at graphicsview/qgraphicsscene.cpp:4919
#14 0x00000032e35be465 in QGraphicsScenePrivate::drawSubtreeRecursive (this=this@entry=0x26247f0, item=0x261fe80, painter=painter@entry=0x7fff233c5f40, viewTransform=viewTransform@entry=0x0, exposedRegion=exposedRegion@entry=0x26253c8, widget=widget@entry=0x263ad80, parentOpacity=parentOpacity@entry=1, effectTransform=effectTransform@entry=0x0) at graphicsview/qgraphicsscene.cpp:4857
#15 0x00000032e35bef3e in QGraphicsScenePrivate::drawItems (this=0x26247f0, painter=0x7fff233c5f40, viewTransform=0x0, exposedRegion=0x26253c8, widget=0x263ad80) at graphicsview/qgraphicsscene.cpp:4739
#16 0x00000032e35db0b8 in QGraphicsView::paintEvent (this=0x2624f10, event=<optimized out>) at graphicsview/qgraphicsview.cpp:3471
#17 0x00000032e3019b02 in QWidget::event (this=0x2624f10, event=0x7fff233c6b90) at kernel/qwidget.cpp:8517
#18 0x00000032e33c3b46 in QFrame::event (this=0x2624f10, e=0x7fff233c6b90) at widgets/qframe.cpp:557
#19 0x00000032e35dc1eb in QGraphicsView::viewportEvent (this=0x2624f10, event=0x7fff233c6b90) at graphicsview/qgraphicsview.cpp:2866
#20 0x00000032e0776556 in QCoreApplicationPrivate::sendThroughObjectEventFilters (this=<optimized out>, receiver=0x263ad80, event=0x7fff233c6b90) at kernel/qcoreapplication.cpp:1025
#21 0x00000032e2fca34c in QApplicationPrivate::notify_helper (this=this@entry=0x204f690, receiver=receiver@entry=0x263ad80, e=e@entry=0x7fff233c6b90) at kernel/qapplication.cpp:4547
#22 0x00000032e2fce7fa in QApplication::notify (this=0x7fff233c9700, receiver=0x263ad80, e=0x7fff233c6b90) at kernel/qapplication.cpp:4412
#23 0x0000003de3046316 in KApplication::notify(QObject*, QEvent*) () from /lib64/libkdeui.so.5
#24 0x00000032e07763ee in QCoreApplication::notifyInternal (this=0x7fff233c9700, receiver=0x263ad80, event=0x7fff233c6b90) at kernel/qcoreapplication.cpp:915
#25 0x00000032e3015814 in sendSpontaneousEvent (event=0x7fff233c6b90, receiver=0x263ad80) at ../../src/corelib/kernel/qcoreapplication.h:234
#26 QWidgetPrivate::drawWidget (this=this@entry=0x263adb0, pdev=pdev@entry=0x2698b90, rgn=..., offset=..., flags=flags@entry=4, sharedPainter=sharedPainter@entry=0x0, backingStore=backingStore@entry=0x24d1ca0) at kernel/qwidget.cpp:5594
#27 0x00000032e301630f in QWidgetPrivate::paintSiblingsRecursive (this=0x2624f40, pdev=0x2698b90, siblings=..., index=<optimized out>, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x24d1ca0) at kernel/qwidget.cpp:5803
#28 0x00000032e30153a5 in QWidgetPrivate::drawWidget (this=this@entry=0x2624f40, pdev=pdev@entry=0x2698b90, rgn=..., offset=..., flags=flags@entry=4, sharedPainter=sharedPainter@entry=0x0, backingStore=backingStore@entry=0x24d1ca0) at kernel/qwidget.cpp:5647
#29 0x00000032e301630f in QWidgetPrivate::paintSiblingsRecursive (this=this@entry=0x261afe0, pdev=pdev@entry=0x2698b90, siblings=..., index=<optimized out>, index@entry=5, rgn=..., offset=..., flags=flags@entry=4, sharedPainter=sharedPainter@entry=0x0, backingStore=backingStore@entry=0x24d1ca0) at kernel/qwidget.cpp:5803
#30 0x00000032e3016154 in QWidgetPrivate::paintSiblingsRecursive (this=0x261afe0, pdev=0x2698b90, siblings=..., index=5, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x24d1ca0) at kernel/qwidget.cpp:5790
#31 0x00000032e30153a5 in QWidgetPrivate::drawWidget (this=this@entry=0x261afe0, pdev=pdev@entry=0x2698b90, rgn=..., offset=..., flags=flags@entry=4, sharedPainter=sharedPainter@entry=0x0, backingStore=backingStore@entry=0x24d1ca0) at kernel/qwidget.cpp:5647
#32 0x00000032e301630f in QWidgetPrivate::paintSiblingsRecursive (this=0x23b50f0, pdev=0x2698b90, siblings=..., index=<optimized out>, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x24d1ca0) at kernel/qwidget.cpp:5803
#33 0x00000032e30153a5 in QWidgetPrivate::drawWidget (this=this@entry=0x23b50f0, pdev=pdev@entry=0x2698b90, rgn=..., offset=..., flags=flags@entry=4, sharedPainter=sharedPainter@entry=0x0, backingStore=backingStore@entry=0x24d1ca0) at kernel/qwidget.cpp:5647
#34 0x00000032e301630f in QWidgetPrivate::paintSiblingsRecursive (this=0x23b3200, pdev=0x2698b90, siblings=..., index=<optimized out>, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x24d1ca0) at kernel/qwidget.cpp:5803
#35 0x00000032e30153a5 in QWidgetPrivate::drawWidget (this=this@entry=0x23b3200, pdev=pdev@entry=0x2698b90, rgn=..., offset=..., flags=flags@entry=4, sharedPainter=sharedPainter@entry=0x0, backingStore=backingStore@entry=0x24d1ca0) at kernel/qwidget.cpp:5647
#36 0x00000032e301630f in QWidgetPrivate::paintSiblingsRecursive (this=0x21c62d0, pdev=0x2698b90, siblings=..., index=<optimized out>, rgn=..., offset=..., flags=4, sharedPainter=0x0, backingStore=0x24d1ca0) at kernel/qwidget.cpp:5803
#37 0x00000032e30153a5 in QWidgetPrivate::drawWidget (this=0x21c62d0, pdev=0x2698b90, rgn=..., offset=..., flags=<optimized out>, sharedPainter=0x0, backingStore=0x24d1ca0) at kernel/qwidget.cpp:5647
#38 0x00000032e31dee48 in QWidgetBackingStore::sync (this=0x24d1ca0) at painting/qbackingstore.cpp:1373
#39 0x00000032e300a340 in QWidgetPrivate::syncBackingStore (this=this@entry=0x21c62d0) at kernel/qwidget.cpp:1892
#40 0x00000032e301a14c in QWidget::event (this=0x21d21a0, event=0x2915890) at kernel/qwidget.cpp:8664
#41 0x00000032e33dd02b in QMainWindow::event (this=0x21d21a0, event=0x2915890) at widgets/qmainwindow.cpp:1478
#42 0x0000003de3137f48 in KXmlGuiWindow::event(QEvent*) () from /lib64/libkdeui.so.5
#43 0x00000032e2fca37c in QApplicationPrivate::notify_helper (this=this@entry=0x204f690, receiver=receiver@entry=0x21d21a0, e=e@entry=0x2915890) at kernel/qapplication.cpp:4551
#44 0x00000032e2fce7fa in QApplication::notify (this=0x7fff233c9700, receiver=0x21d21a0, e=0x2915890) at kernel/qapplication.cpp:4412
#45 0x0000003de3046316 in KApplication::notify(QObject*, QEvent*) () from /lib64/libkdeui.so.5
#46 0x00000032e07763ee in QCoreApplication::notifyInternal (this=0x7fff233c9700, receiver=receiver@entry=0x21d21a0, event=event@entry=0x2915890) at kernel/qcoreapplication.cpp:915
#47 0x00000032e0779ea1 in sendEvent (event=0x2915890, receiver=0x21d21a0) at kernel/qcoreapplication.h:231
#48 QCoreApplicationPrivate::sendPostedEvents (receiver=0x21d21a0, event_type=77, data=0x20207a0) at kernel/qcoreapplication.cpp:1539
#49 0x00000032e35b7e72 in dispatchPendingUpdateRequests (this=0x2624f40) at ../../src/gui/graphicsview/qgraphicsview_p.h:200
#50 QGraphicsScenePrivate::_q_processDirtyItems (this=0x26247f0) at graphicsview/qgraphicsscene.cpp:515
#51 0x00000032e35b8029 in qt_static_metacall (_a=<optimized out>, _id=<optimized out>, _o=<optimized out>, _c=<optimized out>) at .moc/release-shared/moc_qgraphicsscene.cpp:106
#52 QGraphicsScene::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>) at .moc/release-shared/moc_qgraphicsscene.cpp:85
#53 0x00000032e078acee in QObject::event (this=0x26247d0, e=<optimized out>) at kernel/qobject.cpp:1195
#54 0x00000032e35c2a34 in QGraphicsScene::event (this=0x26247d0, event=0x2877dc0) at graphicsview/qgraphicsscene.cpp:3565
#55 0x00000032e2fca37c in QApplicationPrivate::notify_helper (this=this@entry=0x204f690, receiver=receiver@entry=0x26247d0, e=e@entry=0x2877dc0) at kernel/qapplication.cpp:4551
#56 0x00000032e2fce7fa in QApplication::notify (this=0x7fff233c9700, receiver=0x26247d0, e=0x2877dc0) at kernel/qapplication.cpp:4412
#57 0x0000003de3046316 in KApplication::notify(QObject*, QEvent*) () from /lib64/libkdeui.so.5
#58 0x00000032e07763ee in QCoreApplication::notifyInternal (this=0x7fff233c9700, receiver=receiver@entry=0x26247d0, event=event@entry=0x2877dc0) at kernel/qcoreapplication.cpp:915
#59 0x00000032e0779ea1 in sendEvent (event=0x2877dc0, receiver=0x26247d0) at kernel/qcoreapplication.h:231
#60 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x20207a0) at kernel/qcoreapplication.cpp:1539
#61 0x00000032e07a4353 in sendPostedEvents () at kernel/qcoreapplication.h:236
#62 postEventSourceDispatch (s=0x204cac0) at kernel/qeventdispatcher_glib.cpp:279
#63 0x00000032d8e47695 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#64 0x00000032d8e479c8 in ?? () from /lib64/libglib-2.0.so.0
#65 0x00000032d8e47a84 in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#66 0x00000032e07a44e6 in QEventDispatcherGlib::processEvents (this=0x2021c60, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#67 0x00000032e306a2ee in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:207
#68 0x00000032e077513f in QEventLoop::processEvents (this=this@entry=0x7fff233c95c0, flags=...) at kernel/qeventloop.cpp:149
#69 0x00000032e07753c8 in QEventLoop::exec (this=0x7fff233c95c0, flags=...) at kernel/qeventloop.cpp:204
#70 0x00000032e077a1b8 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1187
#71 0x00007fea71110457 in kdemain (argc=5, argv=0x7fff233c9838) at /usr/src/debug/kde-baseapps-4.9.0/dolphin/src/main.cpp:89
#72 0x00000032d5a21735 in __libc_start_main () from /lib64/libc.so.6
#73 0x0000000000400841 in _start ()

Reported using DrKonqi
Comment 1 Kevin Kofler 2012-09-02 22:12:07 UTC
See also https://bugzilla.redhat.com/show_bug.cgi?id=842164
Comment 2 Frank Reininghaus 2012-09-03 11:57:16 UTC
Thanks for the bug report! I don't have any encrypted devices to test with at the moment.

Could you try to generate a Valgrind log? Just to see if something fishy is going on before the crash. At the moment, I can't see from the backtrace alone what the root cause is.
Comment 3 Peter Gückel 2012-09-03 17:56:00 UTC
(In reply to comment #2)
> Could you try to generate a Valgrind log?

I haven't got the foggiest idea what valgrind is or how to generate a valgrind log.
Comment 4 Kevin Kofler 2012-09-03 18:01:45 UTC
su -c "yum install valgrind"
valgrind dolphin 2>valgrind.log

Valgrind is a debugging utility which includes several debugging "tools". The default tool is "memcheck" which catches incorrect use of memory. It can often find the true cause of memory-related crashes when GDB catches only a symptom.
Comment 5 Peter Gückel 2012-09-03 21:45:47 UTC
Created attachment 73635 [details]
valgrind as me
Comment 6 Peter Gückel 2012-09-03 21:46:37 UTC
Created attachment 73636 [details]
valgrind with sudo
Comment 7 Peter Gückel 2012-09-03 21:47:42 UTC
(In reply to comment #4)
> su -c "yum install valgrind"
> valgrind dolphin 2>valgrind.log

I ran valgrind twice, the first time as me, then I closed the loop device. I waited a while, and then typed ctrl-c to stop valgrind, since it didn't stop by itself after dolphin crashed.

I reopened the loop device and ran sudo valgrind, then closed the loop device, and waited, then typed ctrl-c after the crash.

Curiously, the log file as me is larger than the sudo one. Both are attached.
Comment 8 Kevin Kofler 2012-09-03 21:58:37 UTC
Those logs do not show any crash. You say Dolphin crashed, was it another instance of Dolphin? You need to reproduce the crash in the instance running inside Valgrind.
Comment 9 Peter Gückel 2012-09-04 04:19:19 UTC
(In reply to comment #8)
> Those logs do not show any crash. You say Dolphin crashed, was it another
> instance of Dolphin? You need to reproduce the crash in the instance running
> inside Valgrind.

I will try to explain. I have dolphin open in one window and konsole in another window. I run the luks close command in konsole, but dolphin crashes.

The only way I can think of doing what you want is to open a terminal panel in dolphin, run valgrind in that teminal panel embedded in dolphin, and then run the luks close command in konsole, like I usually do.
Comment 10 Peter Gückel 2012-09-04 04:29:21 UTC
(In reply to comment #9)
> The only way I can think of doing what you want is to open a terminal panel
> in dolphin, run valgrind in that teminal panel embedded in dolphin, and then
> run the luks close command in konsole, like I usually do.

I did that and I believe I got exactly the same output again, one showing nothing, if I interpret it correctly (so I deleted those files, the sudo and user versions).

Then, I thought, I should run valgrind in konsole and run the luks close command in the terminal panel that is opened in dolphin, so that is what I have in the 2 files I will post here subsequent to this post.

Also, please tell me whether I should run valgrind as root or as me, so that I don't have to keep making 2 files.
Comment 11 Peter Gückel 2012-09-04 04:30:20 UTC
Created attachment 73640 [details]
new valgrind log run as me
Comment 12 Peter Gückel 2012-09-04 04:30:50 UTC
Created attachment 73641 [details]
new valgrind log run with sudo
Comment 13 Frank Reininghaus 2012-09-04 06:16:53 UTC
Sorry for not explaining what Valgrind is, and thanks for correcting that mistake, Kevin.

The new logs do not show any crash either. You should *not* stop Valgrind manually (as you said in comment 7). You must wait until the crash happens, or there will be no useful info in the log. Note that this can take a while, because Valgrind slows down applications considerably.

About the root/me issue: If you can reproduce the crash with your regular user, also run Valgrind as your regular user. Otherwise, do it as root.

Thanks for your help!
Comment 14 Kevin Kofler 2012-09-04 09:48:15 UTC
> I will try to explain. I have dolphin open in one window and konsole in another window. I
> run the luks close command in konsole, but dolphin crashes.
>
> The only way I can think of doing what you want is to open a terminal panel in dolphin, run
> valgrind in that teminal panel embedded in dolphin, and then run the luks close command
> in konsole, like I usually do.

No, that doesn't make any sense. You're still running 2 instances of Dolphin then, one inside the other, and debugging the wrong one.

You want to run an instance of Konsole, run:
valgrind dolphin 2>valgrind.log
in that instance of Konsole, then run another instance of Konsole (or even just another tab in the same instance of Konsole) and run the luks close command there.
Comment 15 Peter Gückel 2012-09-04 16:17:01 UTC
(In reply to comment #14)
> You want to run an instance of Konsole, run:
> valgrind dolphin 2>valgrind.log
> in that instance of Konsole, then run another instance of Konsole (or even
> just another tab in the same instance of Konsole) and run the luks close
> command there.

OK. I finally got it. Valgrind opens its own copy of dolphin and it starts it very slowly, so I do not open dolphin manually ;-)

So, I did what you said, konsole 2 tabs, dolphin opens up eventually. I opened and closed luks many times, even waited for the valgrind-slowed dolphin to crash for 15 minutes, opened and closed luks yet again to be sure, but nothing happened. Then I manually closed dolphin and checked the valgrind konsole tab, and after a bit, valgrind ended, so I did not issue a ctrl-c.

The log file is much more prodigious. and it actually says 2 errors, so I hope this is what  you need.
Comment 16 Peter Gückel 2012-09-04 16:18:00 UTC
Created attachment 73648 [details]
the one and only true valgrind log file to date, no more sudo
Comment 17 Kevin Kofler 2012-09-04 17:49:51 UTC
Unfortunately, that error can't possibly be it, it's an invalid read (not write) in a completely different location, and I think it's a false positive (it's just a vector read slightly beyond the array boundaries, probably done that way for efficiency, with steps taken to ensure it won't segfault). The logs don't even show a NULL pointer dereference, so unfortunately, you failed (again) to reproduce the bug. :-(

Frank, the problem seems to be that we have a NULL staticText in the KStandardItemListWidget. Attempting to paint that causes the crash. But how the text is becoming NULL in the first place, I don't know. The Valgrind logs are inconclusive because they do not reproduce the bug. (It may or may not be due to a memory corruption. If it is, we should see the memory corruption and then the NULL pointer dereference in the Valgrind log, if not, we should still see the NULL pointer dereference. Right now we don't see anything. :-( )
Comment 18 Frank Reininghaus 2012-09-05 12:06:35 UTC
Thanks for the new log! Even if you could not make Dolphin crash when running in Valgrind, the fact that we don't see any invalid write to memory in the log might indicate that the problem is something else, so this information is valuable in any case.

(In reply to comment #17)
> Frank, the problem seems to be that we have a NULL staticText in the
> KStandardItemListWidget. Attempting to paint that causes the crash. But how
> the text is becoming NULL in the first place, I don't know.

Yes. I'm not familiar with the code in KStandardItemListWidget, but it could be that the widget's paint() function, which seems to assume that the hash m_textInfo always contains the key 'text' with a valid a valid TextInfo* pointer, is called before the hash is initialised.

But I don't see how this can happen. The hash is initialised in updateTextsCache(), which is called via triggerCacheRefreshing() from paint().
Comment 19 Frank Reininghaus 2012-09-05 12:27:11 UTC
Thinking about it again, the initialisation of the hash I mentioned in my last comment will not happen if the widget's index is negative. KItemListView::slotItemsRemoved() sets the index to -1 if an item is removed.

So here is my idea of how the crash might happen:

1. The items are opened in Dolphin, but some of them are never painted on the screen, probably because one would have to scroll down to see them, or because they are not visible for some other reason. Therefore, their widgets' paint() functions are never called, and the hash m_textInfo is never initialised.

2. When the device is closed, KItemListView::slotItemsRemoved() sets the index of the removed widgets to -1.

3. Dolphin tries to animate the removal of the items and therefore tries to paint some items which have not been visible previously. Calling their widgets' paint() functions fails, as described above, because their m_textInfo hash is empty.

To confirm my theory, I have a couple of questions:

1. You said that you were working in Konsole at the time of the crash. Was the Dolphin window visible at all times? Were all items in the folder visible in the view?

2. If one of the questions in 1 was answered with 'no', could you try to keep all items on the device visible in Dolphin while working in Konsole (maybe by working in a folder with less items which all fit into the view)? If closing the device does not crash Dolphin then, this would at least confirm my theory.
Comment 20 Peter Gückel 2012-09-05 19:41:16 UTC
(In reply to comment #19)
> Thinking about it again, the initialisation of the hash I mentioned in my
> last comment will not happen if the widget's index is negative.
> KItemListView::slotItemsRemoved() sets the index to -1 if an item is removed.
> 
> So here is my idea of how the crash might happen:
> 
> 1. The items are opened in Dolphin, but some of them are never painted on
> the screen, probably because one would have to scroll down to see them, or
> because they are not visible for some other reason. Therefore, their
> widgets' paint() functions are never called, and the hash m_textInfo is
> never initialised.
> 
> 2. When the device is closed, KItemListView::slotItemsRemoved() sets the
> index of the removed widgets to -1.
> 
> 3. Dolphin tries to animate the removal of the items and therefore tries to
> paint some items which have not been visible previously. Calling their
> widgets' paint() functions fails, as described above, because their
> m_textInfo hash is empty.
> 
> To confirm my theory, I have a couple of questions:
> 
> 1. You said that you were working in Konsole at the time of the crash. Was
> the Dolphin window visible at all times? Were all items in the folder
> visible in the view?
> 
> 2. If one of the questions in 1 was answered with 'no', could you try to
> keep all items on the device visible in Dolphin while working in Konsole
> (maybe by working in a folder with less items which all fit into the view)?
> If closing the device does not crash Dolphin then, this would at least
> confirm my theory.

I did as you said, by using a terminal panel within dolphin and executing the luks open/close commands from there, whilst keeping the contents of the encrypted file visible in the file manager pane above. One time, I was lucky, and it really didn't crash! There were many, many complaining messages from luks that the device was still in use, etc., so I had to leave the opened directory to the containing one above it, but keeping the directory name of the encrypted file in view, I executed the luks close command again, with success. Enheartened, I repeatedly tried to reproduce the success, and failed each time: it crashed like always. Still, I did get one single instance without a crash. Progress, maybe?
Comment 21 Frank Reininghaus 2012-09-06 07:25:31 UTC
Thanks for the quick reply!

I think that your findings show that I'm not completely wrong. I still don't know why this did not work consistently as a workaround to the crash, but I think that I can commit a patch which at least prevents the crash before KDE 4.9.2 is released. Thanks again for your help!
Comment 22 Peter Gückel 2012-09-09 15:40:41 UTC
(In reply to comment #21)
> I think that your findings show that I'm not completely wrong. I still don't
> know why this did not work consistently as a workaround to the crash, but I
> think that I can commit a patch which at least prevents the crash before KDE
> 4.9.2 is released. Thanks again for your help!

I know you already have an idea, but I just wanted to say that I just replicated the successful closing again. What I did this time was to have the loop device visible in dolphin not only in the file manager pane of dolphin, but to have it simultaneously visible in the left devices pane. I issued the commands in konsole, while on an entirely different virtual desktop, so dolphin was not actually being displayed, but the device and file manager panes were showing the loop device.

I just wanted to add that about the device pane, as I had not thought of it before.
Comment 23 Frank Reininghaus 2012-09-11 17:38:39 UTC
Git commit a502d3970bd0a0eb240c6b0a18e4601538bf9edb by Frank Reininghaus.
Committed on 11/09/2012 at 19:34.
Pushed by freininghaus into branch 'KDE/4.9'.

Fix possible crash in KStandardItemListWidget::paint()

According to the backtrace in the bug report, it is possible that
KStandardItemListWidget::paint() is called if the hash m_textInfo has
not been initialised. The widget's index must be -1 in this case, see
KStandardItemListWidget::triggerCacheRefreshing(). It looks like this
can only happen if the item is about to be removed from the view, see
KItemListView::slotItemsRemoved().

I could not reproduce the crash, so I'm not sure why exactly this
happens, but this commit should at least prevent the crash.
FIXED-IN: 4.9.2

M  +10   -0    dolphin/src/kitemviews/kstandarditemlistwidget.cpp

http://commits.kde.org/kde-baseapps/a502d3970bd0a0eb240c6b0a18e4601538bf9edb
Comment 24 Frank Reininghaus 2012-09-11 17:40:22 UTC
(In reply to comment #22)

Thanks for the additional information and for your help! I'm pretty confident that my commit fixes the crash. If you upgrade to KDE 4.9.2 next month (or at some later point) and you still get the crash, please reopen this report. Thanks!