302264 2012-06-20 20:30:31 +0000 Dolphin crashes when browsing a git repo in a SSHFS-mount 2013-01-15 16:12:33 +0000 1 1 2 Applications dolphin general 2.1 Ubuntu Linux RESOLVED FIXED NOR crash --- 1 wolfgang-wallner dolphin-bugs-null a.j.ball bladud markg85 http://commits.kde.org/kde-baseapps/a9d7ebbc8be0d03104f3b5c620f8da232cd52857 4.10 0 oldest_to_newest 1268254 0 wolfgang-wallner 2012-06-20 20:30:31 +0000 Application: dolphin (2.0) KDE Platform Version: 4.8.3 (4.8.3) Qt Version: 4.8.1 Operating System: Linux 3.2.0-25-generic x86_64 Distribution: Ubuntu 12.04 LTS -- Information about the crash: - What I was doing when the application crashed: Browsing a direrectory that is mounted via sshfs. The crash is reproducable. When I enter the sshfs-mount and browse through the folders, it will crash after a few directories (not always at the same). It happens in all view modes (icons, compact, details). When browsing in details-viewmode, and enabling tree-view, i can open the sshfs-mount by unfolding the tree without a crash. Howeber, entering a directy again crashes dolphin. The crash can be reproduced every time. -- Backtrace: Application: Dolphin (dolphin), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39 [Current thread is 1 (Thread 0x7f8b5deef780 (LWP 8763))] Thread 4 (Thread 0x7f8b49c83700 (LWP 8764)): #0 0x00007f8b5d7bdb03 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007f8b5579cff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f8b5579d124 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f8b5a84e426 in QEventDispatcherGlib::processEvents (this=0x7f8b440008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #4 0x00007f8b5a81dc82 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007f8b5a81ded7 in QEventLoop::exec (this=0x7f8b49c82dd0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f8b5a71cfa7 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #7 0x00007f8b5a7fd9ff in QInotifyFileSystemWatcherEngine::run (this=0x113ede0) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x00007f8b5a71ffcb in QThreadPrivate::start (arg=0x113ede0) at thread/qthread_unix.cpp:298 #9 0x00007f8b56061e9a in start_thread (arg=0x7f8b49c83700) at pthread_create.c:308 #10 0x00007f8b5d7c94bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f8b48b8c700 (LWP 8765)): #0 0x00007f8b5d7bdb03 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007f8b5579cff6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f8b5579d124 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f8b5a84e426 in QEventDispatcherGlib::processEvents (this=0x7f8b3c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #4 0x00007f8b5a81dc82 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007f8b5a81ded7 in QEventLoop::exec (this=0x7f8b48b8bdd0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f8b5a71cfa7 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #7 0x00007f8b5a7fd9ff in QInotifyFileSystemWatcherEngine::run (this=0x1460630) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x00007f8b5a71ffcb in QThreadPrivate::start (arg=0x1460630) at thread/qthread_unix.cpp:298 #9 0x00007f8b56061e9a in start_thread (arg=0x7f8b48b8c700) at pthread_create.c:308 #10 0x00007f8b5d7c94bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f8b425ea700 (LWP 8799)): [KCrash Handler] #6 0x00007f8b5cb36562 in lockInline (this=0x1a38be0) at /usr/include/qt4/QtCore/qmutex.h:187 #7 relock (this=<synthetic pointer>) at /usr/include/qt4/QtCore/qmutex.h:129 #8 UpdateItemStatesThread::run (this=0x1a38bc0) at ../../../dolphin/src/views/versioncontrol/updateitemstatesthread.cpp:67 #9 0x00007f8b5a71ffcb in QThreadPrivate::start (arg=0x1a38bc0) at thread/qthread_unix.cpp:298 #10 0x00007f8b56061e9a in start_thread (arg=0x7f8b425ea700) at pthread_create.c:308 #11 0x00007f8b5d7c94bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f8b5deef780 (LWP 8763)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:39 #1 0x00007f8b5a71ea9b in _q_futex (val2=0, addr2=0x0, timeout=0x0, val=2, op=0, addr=0x191bb10) at thread/qmutex_unix.cpp:99 #2 QMutexPrivate::wait (this=0x191bb10, timeout=<optimized out>) at thread/qmutex_unix.cpp:113 #3 0x00007f8b5a71a86d in QMutex::lockInternal (this=<optimized out>) at thread/qmutex.cpp:450 #4 0x00007f8b5cb3603d in lockInline (this=0x7f8b5cd62b18) at /usr/include/qt4/QtCore/qmutex.h:190 #5 QMutexLocker (m=0x7f8b5cd62b18, this=<synthetic pointer>) at /usr/include/qt4/QtCore/qmutex.h:109 #6 UpdateItemStatesThread::setData (this=0x1a71b40, plugin=0x1130bf0, itemStates=...) at ../../../dolphin/src/views/versioncontrol/updateitemstatesthread.cpp:51 #7 0x00007f8b5cb36af4 in updateItemStates (this=0x16bf3d0) at ../../../dolphin/src/views/versioncontrol/versioncontrolobserver.cpp:262 #8 VersionControlObserver::updateItemStates (this=0x16bf3d0) at ../../../dolphin/src/views/versioncontrol/versioncontrolobserver.cpp:228 #9 0x00007f8b5cb37a2a in VersionControlObserver::verifyDirectory (this=0x16bf3d0) at ../../../dolphin/src/views/versioncontrol/versioncontrolobserver.cpp:182 #10 0x00007f8b5a833281 in QMetaObject::activate (sender=0x16deb40, m=<optimized out>, local_signal_index=<optimized out>, argv=0x0) at kernel/qobject.cpp:3547 #11 0x00007f8b5a838179 in QObject::event (this=0x16deb40, e=<optimized out>) at kernel/qobject.cpp:1157 #12 0x00007f8b59924894 in notify_helper (e=0x7fff2d59c510, receiver=0x16deb40, this=0x109c9b0) at kernel/qapplication.cpp:4559 #13 QApplicationPrivate::notify_helper (this=0x109c9b0, receiver=0x16deb40, e=0x7fff2d59c510) at kernel/qapplication.cpp:4531 #14 0x00007f8b59929713 in QApplication::notify (this=0x7fff2d59c7f0, receiver=0x16deb40, e=0x7fff2d59c510) at kernel/qapplication.cpp:4420 #15 0x00007f8b5b27fbb6 in KApplication::notify (this=0x7fff2d59c7f0, receiver=0x16deb40, event=0x7fff2d59c510) at ../../kdeui/kernel/kapplication.cpp:311 #16 0x00007f8b5a81ee9c in QCoreApplication::notifyInternal (this=0x7fff2d59c7f0, receiver=0x16deb40, event=0x7fff2d59c510) at kernel/qcoreapplication.cpp:876 #17 0x00007f8b5a8501f2 in sendEvent (event=0x7fff2d59c510, receiver=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #18 QTimerInfoList::activateTimers (this=0x109e070) at kernel/qeventdispatcher_unix.cpp:611 #19 0x00007f8b5a84dc0d in timerSourceDispatch (source=<optimized out>) at kernel/qeventdispatcher_glib.cpp:186 #20 timerSourceDispatch (source=<optimized out>) at kernel/qeventdispatcher_glib.cpp:180 #21 0x00007f8b5a84dc31 in idleTimerSourceDispatch (source=<optimized out>) at kernel/qeventdispatcher_glib.cpp:233 #22 0x00007f8b5579cc9a in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x00007f8b5579d060 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x00007f8b5579d124 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x00007f8b5a84e3bf in QEventDispatcherGlib::processEvents (this=0x10794a0, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #26 0x00007f8b599ccd5e in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #27 0x00007f8b5a81dc82 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #28 0x00007f8b5a81ded7 in QEventLoop::exec (this=0x7fff2d59c780, flags=...) at kernel/qeventloop.cpp:204 #29 0x00007f8b5a822f67 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #30 0x00007f8b5dadc4c7 in kdemain (argc=1, argv=0x7fff2d59cd48) at ../../../dolphin/src/main.cpp:89 #31 0x00007f8b5d6f876d in __libc_start_main (main=0x400640 <main(int, char**)>, argc=1, ubp_av=0x7fff2d59cd48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff2d59cd38) at libc-start.c:226 #32 0x0000000000400671 in _start () Reported using DrKonqi 1268404 1 wolfgang-wallner 2012-06-21 11:41:33 +0000 Browsing the SSHFS-mounted directory in a "Save file"-dialog does not crash an application. I tried it creating a new file in Kwrite and saving it on the SSHS-mounted directory. I can enter and leave different directoriess (a few levels deep). Hope this helps :) 1272713 2 markg85 2012-07-04 21:03:23 +0000 (In reply to comment #1) > Browsing the SSHFS-mounted directory in a "Save file"-dialog does not crash > an application. > > I tried it creating a new file in Kwrite and saving it on the SSHS-mounted > directory. > I can enter and leave different directoriess (a few levels deep). > > Hope this helps :) Hmm, from the looks of the backtrace it crashed in a folder that has version control in it. Could you verify that? So, it should crash on one of your folders with version control (cvs?) in it. If it does, we need the folder to fix it :) You can remove everything out the folder till it's as small as possible and still crashing. 1272725 3 wolfgang-wallner 2012-07-04 21:39:39 +0000 (In reply to comment #2) > Hmm, from the looks of the backtrace it crashed in a folder that has version > control in it. Yes, it contains a working copy of a subversion repo. > Could you verify that? So, it should crash on one of your > folders with version control (cvs?) in it. Additional details i know so far: I tried to sshfs-mount a locale copy of the same repo. When i browse this copy on localhost, dolphin does not crash. I also tried to sshfs-mount another remote server, which contains some git-repos. Againg, dolphin does not crash. > If it does, we need the folder to fix it :) > You can remove everything out > the folder till it's as small as possible and still crashing. ok :) 1272739 4 markg85 2012-07-04 22:26:05 +0000 Oke, so it occurs only on mounted SSHFS partitions with a version controlled folder.. ehhh, not everyone has a SSHFS mount which makes this a bit difficult to fix ;) 1273080 5 wolfgang-wallner 2012-07-05 18:01:26 +0000 (In reply to comment #4) > Oke, so it occurs only on mounted SSHFS partitions with a version controlled > folder.. ehhh, not everyone has a SSHFS mount which makes this a bit > difficult to fix ;) I will try to put a minimal working ( = crashing) example on my server. If this works, i will come back and ask you for your public key so you can access the example and hopefully reproduce the bug. 1273121 6 markg85 2012-07-05 18:56:54 +0000 (In reply to comment #5) > (In reply to comment #4) > > Oke, so it occurs only on mounted SSHFS partitions with a version controlled > > folder.. ehhh, not everyone has a SSHFS mount which makes this a bit > > difficult to fix ;) > > I will try to put a minimal working ( = crashing) example on my server. If > this works, i will come back and ask you for your public key so you can > access the example and hopefully reproduce the bug. Hi, I appreciate that effort :) Must be quite a job to get that "working" (read crashing). However, i don't have anything i can mount as SSHFS... yet. I can see if i can mount my local server though i rather prefer something less critical since i'm going to attempt dolphin crashes.. Even though that will not crash my server, it "might" cause some data loss which i rather prevent. 1276909 7 bladud 2012-07-17 15:31:36 +0000 I'm seeing a crash that looks similar with 4.9rc2, when browsing an sshfs mounted folder in dolphin, containing a git repo. It only crashes if the dolphin git plugin is enabled, and it only crashes on first access; after the crash I can restart dolphin and list the folder fine. I have the svn plugin turned off. Does that agree with what you see? 1290692 8 vanmeeuwen 2012-08-24 16:18:31 +0000 Resetting assignee to default as per bug #305719 1304736 9 74459 a.j.ball 2012-10-10 13:32:45 +0000 Created attachment 74459 New crash information added by DrKonqi dolphin (2.0) on KDE Platform 4.8.5 (4.8.5) using Qt 4.8.1 - What I was doing when the application crashed: I had this crash in slightly different circumstances. I had Dolphin in split screen mode, with a local bzr-controlled directory on one side and a network directory (mounted using sshfs/autofs) on the other. It happened while I was compiling a LaTeX document in the former directory (so quite a few files were changing at once). I should mention I have the bzr vcs plugin running in Dolphin. It does not happen all the time. -- Backtrace (Reduced): #6 0x00007fb03a1a8752 in lockInline (this=0x1628990) at /usr/include/qt4/QtCore/qmutex.h:187 #7 relock (this=<synthetic pointer>) at /usr/include/qt4/QtCore/qmutex.h:129 #8 UpdateItemStatesThread::run (this=0x1628970) at ../../../dolphin/src/views/versioncontrol/updateitemstatesthread.cpp:67 #9 0x00007fb037d8cfcb in QThreadPrivate::start (arg=0x1628970) at thread/qthread_unix.cpp:298 #10 0x00007fb0336cfe9a in start_thread (arg=0x7fb017c6d700) at pthread_create.c:308 1304801 10 74465 bladud 2012-10-10 19:03:07 +0000 Created attachment 74465 Patch to hopefully fix the crash I *think* the problem here is that the lock on the list of directory items being released when listing directories. Either due to a misplaced compiler optimisation, or something else, this pattern: lock ..stuff.. const QString directory = getDirectory_from_data_which_may_be_changed_by_another_thread() unlock accessDirectory(directory) relock is being changed to: lock ..stuff.. unlock accessDirectory(getDirectory_from_data_which_may_be_changed_by_another_thread()) relock and the other-thread data is being changed while the directory is being listed, causing the crash. The reason people are finding this with network filesystems is just that directory listing is much slower, so the window to hit the race is wider. Solution is easy: just hold the lock over the call to accessdirectory. There's no real reason not to, especially since we are editing the data it is supposed to protect outside the lock. In most cases the overhead to release and get the lock compared with the directory listing time means this version is probably even faster. I haven't seen the crash with this patch, but it's always been intermittent, so if someone else could confirm, that would be good. 1304823 11 frank78ac 2012-10-10 21:06:56 +0000 Thanks for the analysis and the patch! The backtraces look like there is a deadlock between both threads: Thread 1 is in UpdateItemStatesThread::setData() in line 51 in updateitemstatesthread.cpp. This means that it has the lock on m_itemMutex and tries to get the lock on m_globalPluginMutex. Thread 2 is in UpdateItemStatesThread::run() in line 67 in updateitemstatesthread.cpp. This means that it has the lock on m_globalPluginMutex and tries to get the lock on m_itemMutex. Your patch will indeed fix that because it prevents that thread 1 locks m_itemMutex in the small window (which might not be so small for remote file systems) where thread 2 releases the lock. The only thing that is not clear to me is why this window actually exists - maybe there is a reason to unlock and re-lock the mutex, but I don't see it. An alternative fix would be to change UpdateItemStatesThread::setData() and unlock the first mutex before locking the other one. What do you think? I don't really think that access to shared data in the window where the lock is released is the problem. 1304841 12 bladud 2012-10-10 23:40:00 +0000 Ah - yes, that makes more sense. It didn't occur to me that a deadlock could result in a segfault, actually. I thought it would just hang forever. Releasing the lock earlier in setData would still (in principle) allow the formation of deadlocks, would it not? Because the locks are potentially taken in a different order. Suppose Thread A (in setData) gets itemMutex on line 50, and at the same time Thread B gets PluginMutex on line 63. Then Thread B will try to re-lock itemMutex on line 65 and block because of thread A, while thread A tries to get PluginMutex on line 52 and blocks because of thread B. Deadlock! I admit that I don't see why the window exists either though, which is troubling... Thanks for the quick response 1306121 13 frank78ac 2012-10-15 12:36:50 +0000 Sorry for the late reply, I was away for a couple of days. (In reply to comment #12) > Ah - yes, that makes more sense. It didn't occur to me that a deadlock could > result in a segfault, actually. I thought it would just hang forever. Why it segfaults is not really clear to me either, but the potential deadlock is the only problem that I can see in the code. > Releasing the lock earlier in setData would still (in principle) allow the > formation of deadlocks, would it not? Because the locks are potentially > taken in a different order. I don't think that the locks can be done in a different order. When the compiler reorders statements to optimise the code, it must make sure that the reordered code is semantically equivalent. This would not be the case if mutex locks were reordered - the compiler would generate artificial deadlocks all the time if that was possible. > Suppose Thread A (in setData) gets itemMutex on line 50, and at the same time > Thread B gets PluginMutex on line 63. > > Then Thread B will try to re-lock itemMutex on line 65 and block because of > thread A, while thread A tries to get PluginMutex on line 52 and blocks > because of thread B. Deadlock! This would not be possible if the first mutex was unlocked in setData() before the second one is locked. > I admit that I don't see why the window exists either though, which is > troubling... Probably this is done to make sure that m_itemMutex is unlocked while "m_plugin->beginRetrieval(directory)" is executed in run(), because this call could take quite some time? If m_itemMutex would be locked during this call, any access to UpdateItemStatesThread::itemStates() or UpdateItemStatesThread::retrievedItems() from thread 1 might block the GUI. 1306248 14 bladud 2012-10-15 18:56:50 +0000 > Sorry for the late reply, I was away for a couple of days. That's alright - no need to apologise. > Why it segfaults is not really clear to me either, but the potential > deadlock is the only problem that I can see in the code. One other thing I noticed - we have: Q_ASSERT(!m_itemStates.isEmpty()); followed by: m_itemStates.first() but Q_ASSERT just prints a warning and continues if it is hit (and in any case m_itemStates is not locked at the time), so it doesn't seem impossible that m_itemStates is empty when .first() is called. And actually, if m_plugin is null, we will give a warning and segfault, so maybe that's the problem. > > Releasing the lock earlier in setData would still (in principle) allow the > > formation of deadlocks, would it not? Because the locks are potentially > > taken in a different order. > > I don't think that the locks can be done in a different order. When the > compiler reorders statements to optimise the code, it must make sure that > the reordered code is semantically equivalent. This would not be the case if > mutex locks were reordered - the compiler would generate artificial > deadlocks all the time if that was possible. Sorry, I wasn't very clear - I just meant "sometimes itemMutex is taken first, and sometimes PluginMutex", not that they could be taken in a different order to that written in the code. > > Suppose Thread A (in setData) gets itemMutex on line 50, and at the same time > > Thread B gets PluginMutex on line 63. > > > > Then Thread B will try to re-lock itemMutex on line 65 and block because of > > thread A, while thread A tries to get PluginMutex on line 52 and blocks > > because of thread B. Deadlock! > > This would not be possible if the first mutex was unlocked in setData() > before the second one is locked. You're quite right, that would fix it. I was worried that if run() were called after unlocking the first mutex in setData, but before locking the second, m_itemStates could get listings from the old plugin. We could fix that by just taking PluginMutex first in setData though. > > I admit that I don't see why the window exists either though, which is > > troubling... > > Probably this is done to make sure that m_itemMutex is unlocked while > "m_plugin->beginRetrieval(directory)" is executed in run(), because this > call could take quite some time? If m_itemMutex would be locked during this > call, any access to UpdateItemStatesThread::itemStates() or > UpdateItemStatesThread::retrievedItems() from thread 1 might block the GUI. Makes sense. So what do you think of the following patch? 1306251 15 74568 bladud 2012-10-15 18:59:37 +0000 Created attachment 74568 Patch with even more hope of fixing the crash This patch: - Fixes potential deadlocks by taking the two mutexes in setData in the same order as in run(). - Fixes potential segfaults by checking explicitly under a mutex that m_plugin is not null and m_itemStates is not empty and returning if they are. - Hopefully fixes the crash. 1307104 16 frank78ac 2012-10-18 10:52:27 +0000 Thanks for the updated patch! Can be pushed to 4.9 after considering the comments below. If you don't have a git account, let me know and I'll do it for you. + //The locks are taken in the same order as in run() + //to avoid potential deadlock. Add a space after '//' - that is more consistent with existing code and improves readability. + QMutexLocker pluginLocker(m_globalPluginMutex); QMutexLocker itemLocker(&m_itemMutex); - m_itemStates = itemStates; - QMutexLocker pluginLocker(m_globalPluginMutex); + m_itemStates = itemStates; m_plugin = plugin; Yes, that might be a good way to fix the crash. @@ -58,12 +60,15 @@ void UpdateItemStatesThread::run() Q_ASSERT(m_plugin); QMutexLocker itemLocker(&m_itemMutex); + if ( m_itemStates.isEmpty() ) + return; Not necessary - the Q_ASSERT() at the beginning of that function ensures that m_itemStates is not empty. const QString directory = m_itemStates.first().item.url().directory(KUrl::AppendTrailingSlash); + m_retrievedItems = false; itemLocker.unlock(); Right, m_retrievedItems should also be protected by the mutex, good catch! - if (m_plugin->beginRetrieval(directory)) { + if (m_plugin && m_plugin->beginRetrieval(directory)) { m_plugin cannot be 0 (see Q_ASSERT() in that function). 1307573 17 bladud 2012-10-20 00:54:38 +0000 > Thanks for the updated patch! Can be pushed to 4.9 after considering the > comments below. If you don't have a git account, let me know and I'll do it > for you. Thanks! I have a git account, and I'll go ahead and commit it to 4.9. > Add a space after '//' - that is more consistent with existing code and > improves readability. Sure. > Not necessary - the Q_ASSERT() at the beginning of that function ensures > that m_itemStates is not empty. Ok - I was just being paranoid. 1307579 18 adaptee 2012-10-20 01:28:19 +0000 Strange, why isn't there auto message for http://commits.kde.org/kde-baseapps/4bdf134cbd3543fbf0273ed49e2b13b3ce49744e ? commit 4bdf134cbd3543fbf0273ed49e2b13b3ce49744e Author: Simeon Bird <spb@ias.edu> Date: 22 分钟之前 Fix race condition and deadlock in the version plugin when listing directories is slow. BUG: 302264 FIXED-IN: 4.9.3 1307584 19 bladud 2012-10-20 03:55:01 +0000 Sorry, I committed from the wrong email address... 1322635 20 bladud 2012-12-10 03:08:27 +0000 Ok, actually, this isn't fixed at all (I was able to trigger it fairly reliably again). So, simply not unlocking and relocking the mutex does indeed appear to fix the crash, but I think by accident; not unlocking the mutex means that calls to itemState block while UpdateStateThread::run is in progress, and thus slotThreadFinished is blocked. If slotThreadFinished is not blocked, once it is done deleteLater() is called on the UpdateStateThread. When I compile in debug mode I get a "QThread:destroyed while thread is still running" message before the crash. So I think that somehow this deletion event is getting delivered to the running UpdateStateThread, not the one that just finished. FYI, I can trigger this reliably if I make the itemMutex a ReadWriteLock. The call to setData is a red herring: it's just sitting there blocking in another thread, not doing anything dangerous. 1332315 21 bladud 2013-01-15 16:12:33 +0000 Git commit a9d7ebbc8be0d03104f3b5c620f8da232cd52857 by Simeon Bird. Committed on 13/01/2013 at 19:49. Pushed by sbird into branch 'KDE/4.10'. A crash occurs if updateItemStates runs between the UpdateItemStatesThread finishing and the finished() signal being delivered. In this case, a new thread was not created, because the old thread still existed. However, pendingItemStatesUpdate was not set, because the thread was not running. Instead, the old thread was restarted. This meant that the finished() signal from the first run could be delivered while the thread was running for a second time, causing the thread to be deleted while still running and thus a crash. Solution: set pendingItemStatesUpdate if the thread is non-null, even if it is not running, knowing that slotThreadFinished has not yet run, and will call updateItemStates itself. FIXED-IN: 4.10 REVIEW: 107656 M +1 -1 dolphin/src/views/versioncontrol/versioncontrolobserver.cpp http://commits.kde.org/kde-baseapps/a9d7ebbc8be0d03104f3b5c620f8da232cd52857 74459 2012-10-10 13:32:45 +0000 2012-10-10 13:32:45 +0000 New crash information added by DrKonqi drkonqireport text/plain 8195 a.j.ball QXBwbGljYXRpb246IGRvbHBoaW4gKDIuMCkKS0RFIFBsYXRmb3JtIFZlcnNpb246IDQuOC41ICg0 LjguNSkKUXQgVmVyc2lvbjogNC44LjEKT3BlcmF0aW5nIFN5c3RlbTogTGludXggMy4yLjAtMzEt Z2VuZXJpYyB4ODZfNjQKRGlzdHJpYnV0aW9uOiBVYnVudHUgMTIuMDQuMSBMVFMKCi0tIEluZm9y bWF0aW9uIGFib3V0IHRoZSBjcmFzaDoKLSBXaGF0IEkgd2FzIGRvaW5nIHdoZW4gdGhlIGFwcGxp Y2F0aW9uIGNyYXNoZWQ6CkkgaGFkIHRoaXMgY3Jhc2ggaW4gc2xpZ2h0bHkgZGlmZmVyZW50IGNp cmN1bXN0YW5jZXMuIEkgaGFkIERvbHBoaW4gaW4gc3BsaXQgc2NyZWVuIG1vZGUsIHdpdGggYSBs b2NhbCBienItY29udHJvbGxlZCBkaXJlY3Rvcnkgb24gb25lIHNpZGUgYW5kIGEgbmV0d29yayBk aXJlY3RvcnkgKG1vdW50ZWQgdXNpbmcgc3NoZnMvYXV0b2ZzKSBvbiB0aGUgb3RoZXIuIEl0IGhh cHBlbmVkIHdoaWxlIEkgd2FzIGNvbXBpbGluZyBhIExhVGVYIGRvY3VtZW50IGluIHRoZSBmb3Jt ZXIgZGlyZWN0b3J5IChzbyBxdWl0ZSBhIGZldyBmaWxlcyB3ZXJlIGNoYW5naW5nIGF0IG9uY2Up LiBJIHNob3VsZCBtZW50aW9uIEkgaGF2ZSB0aGUgYnpyIHZjcyBwbHVnaW4gcnVubmluZyBpbiBE b2xwaGluLgoKSXQgZG9lcyBub3QgaGFwcGVuIGFsbCB0aGUgdGltZS4KCi0tIEJhY2t0cmFjZToK QXBwbGljYXRpb246IERvbHBoaW4gKGRvbHBoaW4pLCBzaWduYWw6IFNlZ21lbnRhdGlvbiBmYXVs dApVc2luZyBob3N0IGxpYnRocmVhZF9kYiBsaWJyYXJ5ICIvbGliL3g4Nl82NC1saW51eC1nbnUv bGlidGhyZWFkX2RiLnNvLjEiLgpzeXNjYWxsICgpIGF0IC4uL3N5c2RlcHMvdW5peC9zeXN2L2xp bnV4L3g4Nl82NC9zeXNjYWxsLlM6MzkKW0N1cnJlbnQgdGhyZWFkIGlzIDEgKFRocmVhZCAweDdm YjAzYjU2ODc4MCAoTFdQIDMzNTgpKV0KClRocmVhZCA0IChUaHJlYWQgMHg3ZmIwMjcyZjE3MDAg KExXUCAzMzYwKSk6CiMwICAweDAwMDA3ZmIwM2FlMzE0MDMgaW4gX19HSV9fX3BvbGwgKGZkcz08 b3B0aW1pemVkIG91dD4sIG5mZHM9PG9wdGltaXplZCBvdXQ+LCB0aW1lb3V0PTxvcHRpbWl6ZWQg b3V0PikgYXQgLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgvcG9sbC5jOjg3CiMxICAweDAwMDA3 ZmIwMzJlMGIwMzYgaW4gPz8gKCkgZnJvbSAvbGliL3g4Nl82NC1saW51eC1nbnUvbGliZ2xpYi0y LjAuc28uMAojMiAgMHgwMDAwN2ZiMDMyZTBiMTY0IGluIGdfbWFpbl9jb250ZXh0X2l0ZXJhdGlv biAoKSBmcm9tIC9saWIveDg2XzY0LWxpbnV4LWdudS9saWJnbGliLTIuMC5zby4wCiMzICAweDAw MDA3ZmIwMzdlYmI0MjYgaW4gUUV2ZW50RGlzcGF0Y2hlckdsaWI6OnByb2Nlc3NFdmVudHMgKHRo aXM9MHg3ZmIwMjAwMDA4YzAsIGZsYWdzPS4uLikgYXQga2VybmVsL3FldmVudGRpc3BhdGNoZXJf Z2xpYi5jcHA6NDI2CiM0ICAweDAwMDA3ZmIwMzdlOGFjODIgaW4gUUV2ZW50TG9vcDo6cHJvY2Vz c0V2ZW50cyAodGhpcz08b3B0aW1pemVkIG91dD4sIGZsYWdzPS4uLikgYXQga2VybmVsL3FldmVu dGxvb3AuY3BwOjE0OQojNSAgMHgwMDAwN2ZiMDM3ZThhZWQ3IGluIFFFdmVudExvb3A6OmV4ZWMg KHRoaXM9MHg3ZmIwMjcyZjBkZDAsIGZsYWdzPS4uLikgYXQga2VybmVsL3FldmVudGxvb3AuY3Bw OjIwNAojNiAgMHgwMDAwN2ZiMDM3ZDg5ZmE3IGluIFFUaHJlYWQ6OmV4ZWMgKHRoaXM9PG9wdGlt aXplZCBvdXQ+KSBhdCB0aHJlYWQvcXRocmVhZC5jcHA6NTAxCiM3ICAweDAwMDA3ZmIwMzdlNmE5 ZmYgaW4gUUlub3RpZnlGaWxlU3lzdGVtV2F0Y2hlckVuZ2luZTo6cnVuICh0aGlzPTB4YjY0Njgw KSBhdCBpby9xZmlsZXN5c3RlbXdhdGNoZXJfaW5vdGlmeS5jcHA6MjQ4CiM4ICAweDAwMDA3ZmIw MzdkOGNmY2IgaW4gUVRocmVhZFByaXZhdGU6OnN0YXJ0IChhcmc9MHhiNjQ2ODApIGF0IHRocmVh ZC9xdGhyZWFkX3VuaXguY3BwOjI5OAojOSAgMHgwMDAwN2ZiMDMzNmNmZTlhIGluIHN0YXJ0X3Ro cmVhZCAoYXJnPTB4N2ZiMDI3MmYxNzAwKSBhdCBwdGhyZWFkX2NyZWF0ZS5jOjMwOAojMTAgMHgw MDAwN2ZiMDNhZTNjZGJkIGluIGNsb25lICgpIGF0IC4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4 L3g4Nl82NC9jbG9uZS5TOjExMgojMTEgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCgpUaHJl YWQgMyAoVGhyZWFkIDB4N2ZiMDI2MTJlNzAwIChMV1AgMzM2MSkpOgojMCAgMHgwMDAwN2ZiMDMz NmQxZThjIGluIF9fcHRocmVhZF9tdXRleF9sb2NrIChtdXRleD0weDdmYjAxODAwMGE2MCkgYXQg cHRocmVhZF9tdXRleF9sb2NrLmM6NTAKIzEgIDB4MDAwMDdmYjAzMmU0NjVhMSBpbiBnX211dGV4 X2xvY2sgKCkgZnJvbSAvbGliL3g4Nl82NC1saW51eC1nbnUvbGliZ2xpYi0yLjAuc28uMAojMiAg MHgwMDAwN2ZiMDMyZTBhYzM2IGluIGdfbWFpbl9jb250ZXh0X2Rpc3BhdGNoICgpIGZyb20gL2xp Yi94ODZfNjQtbGludXgtZ251L2xpYmdsaWItMi4wLnNvLjAKIzMgIDB4MDAwMDdmYjAzMmUwYjBh MCBpbiA/PyAoKSBmcm9tIC9saWIveDg2XzY0LWxpbnV4LWdudS9saWJnbGliLTIuMC5zby4wCiM0 ICAweDAwMDA3ZmIwMzJlMGIxNjQgaW4gZ19tYWluX2NvbnRleHRfaXRlcmF0aW9uICgpIGZyb20g L2xpYi94ODZfNjQtbGludXgtZ251L2xpYmdsaWItMi4wLnNvLjAKIzUgIDB4MDAwMDdmYjAzN2Vi YjQyNiBpbiBRRXZlbnREaXNwYXRjaGVyR2xpYjo6cHJvY2Vzc0V2ZW50cyAodGhpcz0weDdmYjAx ODAwMDhjMCwgZmxhZ3M9Li4uKSBhdCBrZXJuZWwvcWV2ZW50ZGlzcGF0Y2hlcl9nbGliLmNwcDo0 MjYKIzYgIDB4MDAwMDdmYjAzN2U4YWM4MiBpbiBRRXZlbnRMb29wOjpwcm9jZXNzRXZlbnRzICh0 aGlzPTxvcHRpbWl6ZWQgb3V0PiwgZmxhZ3M9Li4uKSBhdCBrZXJuZWwvcWV2ZW50bG9vcC5jcHA6 MTQ5CiM3ICAweDAwMDA3ZmIwMzdlOGFlZDcgaW4gUUV2ZW50TG9vcDo6ZXhlYyAodGhpcz0weDdm YjAyNjEyZGRkMCwgZmxhZ3M9Li4uKSBhdCBrZXJuZWwvcWV2ZW50bG9vcC5jcHA6MjA0CiM4ICAw eDAwMDA3ZmIwMzdkODlmYTcgaW4gUVRocmVhZDo6ZXhlYyAodGhpcz08b3B0aW1pemVkIG91dD4p IGF0IHRocmVhZC9xdGhyZWFkLmNwcDo1MDEKIzkgIDB4MDAwMDdmYjAzN2U2YTlmZiBpbiBRSW5v dGlmeUZpbGVTeXN0ZW1XYXRjaGVyRW5naW5lOjpydW4gKHRoaXM9MHhjMjMwODApIGF0IGlvL3Fm aWxlc3lzdGVtd2F0Y2hlcl9pbm90aWZ5LmNwcDoyNDgKIzEwIDB4MDAwMDdmYjAzN2Q4Y2ZjYiBp biBRVGhyZWFkUHJpdmF0ZTo6c3RhcnQgKGFyZz0weGMyMzA4MCkgYXQgdGhyZWFkL3F0aHJlYWRf dW5peC5jcHA6Mjk4CiMxMSAweDAwMDA3ZmIwMzM2Y2ZlOWEgaW4gc3RhcnRfdGhyZWFkIChhcmc9 MHg3ZmIwMjYxMmU3MDApIGF0IHB0aHJlYWRfY3JlYXRlLmM6MzA4CiMxMiAweDAwMDA3ZmIwM2Fl M2NkYmQgaW4gY2xvbmUgKCkgYXQgLi4vc3lzZGVwcy91bml4L3N5c3YvbGludXgveDg2XzY0L2Ns b25lLlM6MTEyCiMxMyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKClRocmVhZCAyIChUaHJl YWQgMHg3ZmIwMTdjNmQ3MDAgKExXUCA4NDc4KSk6CltLQ3Jhc2ggSGFuZGxlcl0KIzYgIDB4MDAw MDdmYjAzYTFhODc1MiBpbiBsb2NrSW5saW5lICh0aGlzPTB4MTYyODk5MCkgYXQgL3Vzci9pbmNs dWRlL3F0NC9RdENvcmUvcW11dGV4Lmg6MTg3CiM3ICByZWxvY2sgKHRoaXM9PHN5bnRoZXRpYyBw b2ludGVyPikgYXQgL3Vzci9pbmNsdWRlL3F0NC9RdENvcmUvcW11dGV4Lmg6MTI5CiM4ICBVcGRh dGVJdGVtU3RhdGVzVGhyZWFkOjpydW4gKHRoaXM9MHgxNjI4OTcwKSBhdCAuLi8uLi8uLi9kb2xw aGluL3NyYy92aWV3cy92ZXJzaW9uY29udHJvbC91cGRhdGVpdGVtc3RhdGVzdGhyZWFkLmNwcDo2 NwojOSAgMHgwMDAwN2ZiMDM3ZDhjZmNiIGluIFFUaHJlYWRQcml2YXRlOjpzdGFydCAoYXJnPTB4 MTYyODk3MCkgYXQgdGhyZWFkL3F0aHJlYWRfdW5peC5jcHA6Mjk4CiMxMCAweDAwMDA3ZmIwMzM2 Y2ZlOWEgaW4gc3RhcnRfdGhyZWFkIChhcmc9MHg3ZmIwMTdjNmQ3MDApIGF0IHB0aHJlYWRfY3Jl YXRlLmM6MzA4CiMxMSAweDAwMDA3ZmIwM2FlM2NkYmQgaW4gY2xvbmUgKCkgYXQgLi4vc3lzZGVw cy91bml4L3N5c3YvbGludXgveDg2XzY0L2Nsb25lLlM6MTEyCiMxMiAweDAwMDAwMDAwMDAwMDAw MDAgaW4gPz8gKCkKClRocmVhZCAxIChUaHJlYWQgMHg3ZmIwM2I1Njg3ODAgKExXUCAzMzU4KSk6 CiMwICBzeXNjYWxsICgpIGF0IC4uL3N5c2RlcHMvdW5peC9zeXN2L2xpbnV4L3g4Nl82NC9zeXNj YWxsLlM6MzkKIzEgIDB4MDAwMDdmYjAzN2Q4YmE5YiBpbiBfcV9mdXRleCAodmFsMj0wLCBhZGRy Mj0weDAsIHRpbWVvdXQ9MHgwLCB2YWw9Miwgb3A9MCwgYWRkcj0weDEyYWFlODApIGF0IHRocmVh ZC9xbXV0ZXhfdW5peC5jcHA6OTkKIzIgIFFNdXRleFByaXZhdGU6OndhaXQgKHRoaXM9MHgxMmFh ZTgwLCB0aW1lb3V0PTxvcHRpbWl6ZWQgb3V0PikgYXQgdGhyZWFkL3FtdXRleF91bml4LmNwcDox MTMKIzMgIDB4MDAwMDdmYjAzN2Q4Nzg2ZCBpbiBRTXV0ZXg6OmxvY2tJbnRlcm5hbCAodGhpcz08 b3B0aW1pemVkIG91dD4pIGF0IHRocmVhZC9xbXV0ZXguY3BwOjQ1MAojNCAgMHgwMDAwN2ZiMDNh MWE4MjJkIGluIGxvY2tJbmxpbmUgKHRoaXM9MHg3ZmIwM2EzZDRiMTgpIGF0IC91c3IvaW5jbHVk ZS9xdDQvUXRDb3JlL3FtdXRleC5oOjE5MAojNSAgUU11dGV4TG9ja2VyIChtPTB4N2ZiMDNhM2Q0 YjE4LCB0aGlzPTxzeW50aGV0aWMgcG9pbnRlcj4pIGF0IC91c3IvaW5jbHVkZS9xdDQvUXRDb3Jl L3FtdXRleC5oOjEwOQojNiAgVXBkYXRlSXRlbVN0YXRlc1RocmVhZDo6c2V0RGF0YSAodGhpcz0w eDE1YmVmOTAsIHBsdWdpbj0weDExNzM0ODAsIGl0ZW1TdGF0ZXM9Li4uKSBhdCAuLi8uLi8uLi9k b2xwaGluL3NyYy92aWV3cy92ZXJzaW9uY29udHJvbC91cGRhdGVpdGVtc3RhdGVzdGhyZWFkLmNw cDo1MQojNyAgMHgwMDAwN2ZiMDNhMWE4Y2U0IGluIHVwZGF0ZUl0ZW1TdGF0ZXMgKHRoaXM9MHhj NTJiNDApIGF0IC4uLy4uLy4uL2RvbHBoaW4vc3JjL3ZpZXdzL3ZlcnNpb25jb250cm9sL3ZlcnNp b25jb250cm9sb2JzZXJ2ZXIuY3BwOjI2MgojOCAgVmVyc2lvbkNvbnRyb2xPYnNlcnZlcjo6dXBk YXRlSXRlbVN0YXRlcyAodGhpcz0weGM1MmI0MCkgYXQgLi4vLi4vLi4vZG9scGhpbi9zcmMvdmll d3MvdmVyc2lvbmNvbnRyb2wvdmVyc2lvbmNvbnRyb2xvYnNlcnZlci5jcHA6MjI4CiM5ICAweDAw MDA3ZmIwM2ExYTljMWEgaW4gVmVyc2lvbkNvbnRyb2xPYnNlcnZlcjo6dmVyaWZ5RGlyZWN0b3J5 ICh0aGlzPTB4YzUyYjQwKSBhdCAuLi8uLi8uLi9kb2xwaGluL3NyYy92aWV3cy92ZXJzaW9uY29u dHJvbC92ZXJzaW9uY29udHJvbG9ic2VydmVyLmNwcDoxODIKIzEwIDB4MDAwMDdmYjAzN2VhMDI4 MSBpbiBRTWV0YU9iamVjdDo6YWN0aXZhdGUgKHNlbmRlcj0weGJmNWMxMCwgbT08b3B0aW1pemVk IG91dD4sIGxvY2FsX3NpZ25hbF9pbmRleD08b3B0aW1pemVkIG91dD4sIGFyZ3Y9MHgwKSBhdCBr ZXJuZWwvcW9iamVjdC5jcHA6MzU0NwojMTEgMHgwMDAwN2ZiMDM3ZWE1MTc5IGluIFFPYmplY3Q6 OmV2ZW50ICh0aGlzPTB4YmY1YzEwLCBlPTxvcHRpbWl6ZWQgb3V0PikgYXQga2VybmVsL3FvYmpl Y3QuY3BwOjExNTcKIzEyIDB4MDAwMDdmYjAzNmY5MTg5NCBpbiBub3RpZnlfaGVscGVyIChlPTB4 N2ZmZmVjMTA3YzgwLCByZWNlaXZlcj0weGJmNWMxMCwgdGhpcz0weDlhMmQ3MCkgYXQga2VybmVs L3FhcHBsaWNhdGlvbi5jcHA6NDU1OQojMTMgUUFwcGxpY2F0aW9uUHJpdmF0ZTo6bm90aWZ5X2hl bHBlciAodGhpcz0weDlhMmQ3MCwgcmVjZWl2ZXI9MHhiZjVjMTAsIGU9MHg3ZmZmZWMxMDdjODAp IGF0IGtlcm5lbC9xYXBwbGljYXRpb24uY3BwOjQ1MzEKIzE0IDB4MDAwMDdmYjAzNmY5NjcxMyBp biBRQXBwbGljYXRpb246Om5vdGlmeSAodGhpcz0weDdmZmZlYzEwN2Y2MCwgcmVjZWl2ZXI9MHhi ZjVjMTAsIGU9MHg3ZmZmZWMxMDdjODApIGF0IGtlcm5lbC9xYXBwbGljYXRpb24uY3BwOjQ0MjAK IzE1IDB4MDAwMDdmYjAzODhmMTNmNiBpbiBLQXBwbGljYXRpb246Om5vdGlmeSAodGhpcz0weDdm ZmZlYzEwN2Y2MCwgcmVjZWl2ZXI9MHhiZjVjMTAsIGV2ZW50PTB4N2ZmZmVjMTA3YzgwKSBhdCAu Li8uLi9rZGV1aS9rZXJuZWwva2FwcGxpY2F0aW9uLmNwcDozMTEKIzE2IDB4MDAwMDdmYjAzN2U4 YmU5YyBpbiBRQ29yZUFwcGxpY2F0aW9uOjpub3RpZnlJbnRlcm5hbCAodGhpcz0weDdmZmZlYzEw N2Y2MCwgcmVjZWl2ZXI9MHhiZjVjMTAsIGV2ZW50PTB4N2ZmZmVjMTA3YzgwKSBhdCBrZXJuZWwv cWNvcmVhcHBsaWNhdGlvbi5jcHA6ODc2CiMxNyAweDAwMDA3ZmIwMzdlYmQxZjIgaW4gc2VuZEV2 ZW50IChldmVudD0weDdmZmZlYzEwN2M4MCwgcmVjZWl2ZXI9PG9wdGltaXplZCBvdXQ+KSBhdCAu Li8uLi9pbmNsdWRlL1F0Q29yZS8uLi8uLi9zcmMvY29yZWxpYi9rZXJuZWwvcWNvcmVhcHBsaWNh dGlvbi5oOjIzMQojMTggUVRpbWVySW5mb0xpc3Q6OmFjdGl2YXRlVGltZXJzICh0aGlzPTB4OWE0 MDgwKSBhdCBrZXJuZWwvcWV2ZW50ZGlzcGF0Y2hlcl91bml4LmNwcDo2MTEKIzE5IDB4MDAwMDdm YjAzN2ViYWMwZCBpbiB0aW1lclNvdXJjZURpc3BhdGNoIChzb3VyY2U9PG9wdGltaXplZCBvdXQ+ KSBhdCBrZXJuZWwvcWV2ZW50ZGlzcGF0Y2hlcl9nbGliLmNwcDoxODYKIzIwIHRpbWVyU291cmNl RGlzcGF0Y2ggKHNvdXJjZT08b3B0aW1pemVkIG91dD4pIGF0IGtlcm5lbC9xZXZlbnRkaXNwYXRj aGVyX2dsaWIuY3BwOjE4MAojMjEgMHgwMDAwN2ZiMDM3ZWJhYzMxIGluIGlkbGVUaW1lclNvdXJj ZURpc3BhdGNoIChzb3VyY2U9PG9wdGltaXplZCBvdXQ+KSBhdCBrZXJuZWwvcWV2ZW50ZGlzcGF0 Y2hlcl9nbGliLmNwcDoyMzMKIzIyIDB4MDAwMDdmYjAzMmUwYWQ1MyBpbiBnX21haW5fY29udGV4 dF9kaXNwYXRjaCAoKSBmcm9tIC9saWIveDg2XzY0LWxpbnV4LWdudS9saWJnbGliLTIuMC5zby4w CiMyMyAweDAwMDA3ZmIwMzJlMGIwYTAgaW4gPz8gKCkgZnJvbSAvbGliL3g4Nl82NC1saW51eC1n bnUvbGliZ2xpYi0yLjAuc28uMAojMjQgMHgwMDAwN2ZiMDMyZTBiMTY0IGluIGdfbWFpbl9jb250 ZXh0X2l0ZXJhdGlvbiAoKSBmcm9tIC9saWIveDg2XzY0LWxpbnV4LWdudS9saWJnbGliLTIuMC5z by4wCiMyNSAweDAwMDA3ZmIwMzdlYmIzYmYgaW4gUUV2ZW50RGlzcGF0Y2hlckdsaWI6OnByb2Nl c3NFdmVudHMgKHRoaXM9MHg5N2U0YTAsIGZsYWdzPS4uLikgYXQga2VybmVsL3FldmVudGRpc3Bh dGNoZXJfZ2xpYi5jcHA6NDI0CiMyNiAweDAwMDA3ZmIwMzcwMzlkNWUgaW4gUUd1aUV2ZW50RGlz cGF0Y2hlckdsaWI6OnByb2Nlc3NFdmVudHMgKHRoaXM9PG9wdGltaXplZCBvdXQ+LCBmbGFncz0u Li4pIGF0IGtlcm5lbC9xZ3VpZXZlbnRkaXNwYXRjaGVyX2dsaWIuY3BwOjIwNAojMjcgMHgwMDAw N2ZiMDM3ZThhYzgyIGluIFFFdmVudExvb3A6OnByb2Nlc3NFdmVudHMgKHRoaXM9PG9wdGltaXpl ZCBvdXQ+LCBmbGFncz0uLi4pIGF0IGtlcm5lbC9xZXZlbnRsb29wLmNwcDoxNDkKIzI4IDB4MDAw MDdmYjAzN2U4YWVkNyBpbiBRRXZlbnRMb29wOjpleGVjICh0aGlzPTB4N2ZmZmVjMTA3ZWYwLCBm bGFncz0uLi4pIGF0IGtlcm5lbC9xZXZlbnRsb29wLmNwcDoyMDQKIzI5IDB4MDAwMDdmYjAzN2U4 ZmY2NyBpbiBRQ29yZUFwcGxpY2F0aW9uOjpleGVjICgpIGF0IGtlcm5lbC9xY29yZWFwcGxpY2F0 aW9uLmNwcDoxMTQ4CiMzMCAweDAwMDA3ZmIwM2IxNTA0YzcgaW4ga2RlbWFpbiAoYXJnYz02LCBh cmd2PTB4N2ZmZmVjMTA4NGI4KSBhdCAuLi8uLi8uLi9kb2xwaGluL3NyYy9tYWluLmNwcDo4OQoj MzEgMHgwMDAwN2ZiMDNhZDZhNzZkIGluIF9fbGliY19zdGFydF9tYWluIChtYWluPTB4NDAwNjQw IDxtYWluKGludCwgY2hhcioqKT4sIGFyZ2M9NiwgdWJwX2F2PTB4N2ZmZmVjMTA4NGI4LCBpbml0 PTxvcHRpbWl6ZWQgb3V0PiwgZmluaT08b3B0aW1pemVkIG91dD4sIHJ0bGRfZmluaT08b3B0aW1p emVkIG91dD4sIHN0YWNrX2VuZD0weDdmZmZlYzEwODRhOCkgYXQgbGliYy1zdGFydC5jOjIyNgoj MzIgMHgwMDAwMDAwMDAwNDAwNjcxIGluIF9zdGFydCAoKQoKUG9zc2libGUgZHVwbGljYXRlcyBi eSBxdWVyeTogYnVnIDMwMjI2NC4KClJlcG9ydGVkIHVzaW5nIERyS29ucWk= 74465 2012-10-10 19:03:07 +0000 2012-10-10 19:03:07 +0000 Patch to hopefully fix the crash bugfix.patch text/plain 833 bladud ZGlmZiAtLWdpdCBhL2RvbHBoaW4vc3JjL3ZpZXdzL3ZlcnNpb25jb250cm9sL3VwZGF0ZWl0ZW1z dGF0ZXN0aHJlYWQuY3BwIGIvZG9scGhpbi9zcmMvdmlld3MvdmVyc2lvbmNvbnRyb2wvdXBkYXRl aXRlbXN0YXRlc3RocmVhZC5jcHAKaW5kZXggZjk3NDZhYS4uMzhhZDQ0ZSAxMDA2NDQKLS0tIGEv ZG9scGhpbi9zcmMvdmlld3MvdmVyc2lvbmNvbnRyb2wvdXBkYXRlaXRlbXN0YXRlc3RocmVhZC5j cHAKKysrIGIvZG9scGhpbi9zcmMvdmlld3MvdmVyc2lvbmNvbnRyb2wvdXBkYXRlaXRlbXN0YXRl c3RocmVhZC5jcHAKQEAgLTU5LDEyICs1OSwxMCBAQCB2b2lkIFVwZGF0ZUl0ZW1TdGF0ZXNUaHJl YWQ6OnJ1bigpCiAKICAgICBRTXV0ZXhMb2NrZXIgaXRlbUxvY2tlcigmbV9pdGVtTXV0ZXgpOwog ICAgIGNvbnN0IFFTdHJpbmcgZGlyZWN0b3J5ID0gbV9pdGVtU3RhdGVzLmZpcnN0KCkuaXRlbS51 cmwoKS5kaXJlY3RvcnkoS1VybDo6QXBwZW5kVHJhaWxpbmdTbGFzaCk7Ci0gICAgaXRlbUxvY2tl ci51bmxvY2soKTsKIAogICAgIFFNdXRleExvY2tlciBwbHVnaW5Mb2NrZXIobV9nbG9iYWxQbHVn aW5NdXRleCk7CiAgICAgbV9yZXRyaWV2ZWRJdGVtcyA9IGZhbHNlOwogICAgIGlmIChtX3BsdWdp bi0+YmVnaW5SZXRyaWV2YWwoZGlyZWN0b3J5KSkgewotICAgICAgICBpdGVtTG9ja2VyLnJlbG9j aygpOwogICAgICAgICBjb25zdCBpbnQgY291bnQgPSBtX2l0ZW1TdGF0ZXMuY291bnQoKTsKIAog ICAgICAgICBLVmVyc2lvbkNvbnRyb2xQbHVnaW4yKiBwbHVnaW5WMiA9IHFvYmplY3RfY2FzdDxL VmVyc2lvbkNvbnRyb2xQbHVnaW4yKj4obV9wbHVnaW4pOwo= 74568 2012-10-15 18:59:37 +0000 2012-10-15 18:59:37 +0000 Patch with even more hope of fixing the crash bugfix.patch text/plain 1488 bladud ZGlmZiAtLWdpdCBhL2RvbHBoaW4vc3JjL3ZpZXdzL3ZlcnNpb25jb250cm9sL3VwZGF0ZWl0ZW1z dGF0ZXN0aHJlYWQuY3BwIGIvZG9scGhpbi9zcmMvdmlld3MvdmVyc2lvbmNvbnRyb2wvdXBkYXRl aXRlbXN0YXRlc3RocmVhZC5jcHAKaW5kZXggZjk3NDZhYS4uNzMzZjUxOSAxMDA2NDQKLS0tIGEv ZG9scGhpbi9zcmMvdmlld3MvdmVyc2lvbmNvbnRyb2wvdXBkYXRlaXRlbXN0YXRlc3RocmVhZC5j cHAKKysrIGIvZG9scGhpbi9zcmMvdmlld3MvdmVyc2lvbmNvbnRyb2wvdXBkYXRlaXRlbXN0YXRl c3RocmVhZC5jcHAKQEAgLTQ1LDEwICs0NSwxMiBAQCBVcGRhdGVJdGVtU3RhdGVzVGhyZWFkOjp+ VXBkYXRlSXRlbVN0YXRlc1RocmVhZCgpCiB2b2lkIFVwZGF0ZUl0ZW1TdGF0ZXNUaHJlYWQ6OnNl dERhdGEoS1ZlcnNpb25Db250cm9sUGx1Z2luKiBwbHVnaW4sCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29uc3QgUUxpc3Q8VmVyc2lvbkNvbnRyb2xPYnNlcnZlcjo6SXRl bVN0YXRlPiYgaXRlbVN0YXRlcykKIHsKKyAgICAvL1RoZSBsb2NrcyBhcmUgdGFrZW4gaW4gdGhl IHNhbWUgb3JkZXIgYXMgaW4gcnVuKCkKKyAgICAvL3RvIGF2b2lkIHBvdGVudGlhbCBkZWFkbG9j ay4KKyAgICBRTXV0ZXhMb2NrZXIgcGx1Z2luTG9ja2VyKG1fZ2xvYmFsUGx1Z2luTXV0ZXgpOwog ICAgIFFNdXRleExvY2tlciBpdGVtTG9ja2VyKCZtX2l0ZW1NdXRleCk7Ci0gICAgbV9pdGVtU3Rh dGVzID0gaXRlbVN0YXRlczsKIAotICAgIFFNdXRleExvY2tlciBwbHVnaW5Mb2NrZXIobV9nbG9i YWxQbHVnaW5NdXRleCk7CisgICAgbV9pdGVtU3RhdGVzID0gaXRlbVN0YXRlczsKICAgICBtX3Bs dWdpbiA9IHBsdWdpbjsKIH0KIApAQCAtNTgsMTIgKzYwLDE1IEBAIHZvaWQgVXBkYXRlSXRlbVN0 YXRlc1RocmVhZDo6cnVuKCkKICAgICBRX0FTU0VSVChtX3BsdWdpbik7CiAKICAgICBRTXV0ZXhM b2NrZXIgaXRlbUxvY2tlcigmbV9pdGVtTXV0ZXgpOworICAgIGlmICggbV9pdGVtU3RhdGVzLmlz RW1wdHkoKSApCisgICAgICAgIHJldHVybjsKKwogICAgIGNvbnN0IFFTdHJpbmcgZGlyZWN0b3J5 ID0gbV9pdGVtU3RhdGVzLmZpcnN0KCkuaXRlbS51cmwoKS5kaXJlY3RvcnkoS1VybDo6QXBwZW5k VHJhaWxpbmdTbGFzaCk7CisgICAgbV9yZXRyaWV2ZWRJdGVtcyA9IGZhbHNlOwogICAgIGl0ZW1M b2NrZXIudW5sb2NrKCk7CiAKICAgICBRTXV0ZXhMb2NrZXIgcGx1Z2luTG9ja2VyKG1fZ2xvYmFs UGx1Z2luTXV0ZXgpOwotICAgIG1fcmV0cmlldmVkSXRlbXMgPSBmYWxzZTsKLSAgICBpZiAobV9w bHVnaW4tPmJlZ2luUmV0cmlldmFsKGRpcmVjdG9yeSkpIHsKKyAgICBpZiAobV9wbHVnaW4gJiYg bV9wbHVnaW4tPmJlZ2luUmV0cmlldmFsKGRpcmVjdG9yeSkpIHsKICAgICAgICAgaXRlbUxvY2tl ci5yZWxvY2soKTsKICAgICAgICAgY29uc3QgaW50IGNvdW50ID0gbV9pdGVtU3RhdGVzLmNvdW50 KCk7CiAK