| Summary: | Cryptsetup crashes Dolphin on Closing of Loop Device | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | Peter Gückel <pgueckel> |
| Component: | general | Assignee: | 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: | http://commits.kde.org/kde-baseapps/a502d3970bd0a0eb240c6b0a18e4601538bf9edb | Version Fixed In: | 4.9.2 |
| Sentry Crash Report: | |||
| 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
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. (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. 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. Created attachment 73635 [details]
valgrind as me
Created attachment 73636 [details]
valgrind with sudo
(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. 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. (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. (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. Created attachment 73640 [details]
new valgrind log run as me
Created attachment 73641 [details]
new valgrind log run with sudo
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! > 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. (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. Created attachment 73648 [details]
the one and only true valgrind log file to date, no more sudo
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. :-( ) 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(). 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. (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? 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! (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. 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 (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! |