| Summary: | plasmashell hangs every few minutes without apparent reason. | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | dmidge <quelque_ri1> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED FIXED | ||
| Severity: | grave | CC: | bhush94, bugs.kde, plasma-bugs, quelque_ri1, yyc1992 |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
dmidge
2015-04-05 20:28:43 UTC
Look in .cache for a file ending in .lock. After 3 minutes plasma saves any pending cached images to this file, but here it's blocking because it thinks someone else has that file open. Hopefully this lock file shouldn't left anymore after a change I made around January. And you are right! You nailed the problem! Good news then! By removing the file ".cache/plasma-svgelements-default_v0.9.7.lock", everything works perfectly again! So at least, I have a better temporary solution than just kill and launch again. But isn't KF 5.8.0 supposed to be the last version? Besides, when I execute this command: xxxxx$ plasmashell --version plasmashell 5.2.2 If I am right, it is the last version, shipped at the end of march. That means that another similar bug occurs with this version again, unfortunately. Unless your patch hasn't been applied yet, of course. But it is on the good path, at least! I had few hangs since I deleted the lock file, which means the problem is not solved yet. To delete the file once is not enough: time to time, I have to repeat the operation when I am using the computer. But at least, you have spotted the problem! So don't close the bug file now, I still need a patch. Don't hesitate to ask if you have more questions. OK, thanks for reporting back. OK, next time can you attach the file. also run ls -l on the file so I can see the timestamp of it. It is a completely blank file. (Bugzilla don't even want to attach it because of that). There is the ls -l: me$ ls -l .cache/plasma-svgelements-default_v0.9.7.lock -rw-r--r-- 1 me users 0 6 avril 09:23 .cache/plasma-svgelements-default_v0.9.7.lock Blah, there's a bug in QLockFile
bool QLockFilePrivate::isApparentlyStale() const
{
if (!getLockInfo(&pid, &hostname, &appname))
return false;
if it can't read the lock file information, it assumes it's not stale at which point we block forever, waiting for the lock to become stale which will never happen.
Doesn't explain why Qt is writing empty lock files, but that's another story.
Arff, bad luck! That means that we should notify this problem to the Qt team then. I am not sure that I will be able to give as much as you about that bug to the Qt team. Maybe can you contact them and explain them the issue, so they can fix it on their own. But if I get what you're saying, having an empty lock should never happen. Maybe it is possible to fix this side of the problem? At least if you (or the KDE team) can fix it: I won't be able to dive in the code myself in the following days. Hopefully, the freeze caused by blank lock file issue will be fixed soon by the Qt team. I just want to add something: once the lock file has been removed manually, the system becomes more reliable. Meaning that, for the last 70 minutes, I didn't have any freeze, which was not possible before. But yesterday, I experienced few crashes, even after I removed the lock file, but not today. By the way, I gave you the information on the lock file when I was running Gnome, so this lock was there when I killed plasmashell and then rebooted through tty. I don't know if it changes anything, but I hope not. And since it didn't crashed again since I deleted it manually, I can't check the information I got through Gnome. I should add something. I had another unexpected problem that prevented me to reach the KDE desktop (impossible to complete the KDE interface boot part). The solution was also to remove the *.lock files. The symptoms and everything were very similar to what is described there: https://bbs.archlinux.org/viewtopic.php?id=195729. I didn't checked if the lock files were empty or not, but the same operation (deleting every *.lock) solved my problem. That means the Qt lock file problem is a bigger issue than expected! I think a major fix is needed soon! I don't know if you managed to give this information to the concerned team though. In the meantime, I have a question. Why are the lock files in the .config/ folder. Shouldn't they be in the cache folder? By definition, they are temporary files, that don't help to configure the KDE interface. Besides, the common procedure, when KDE fails to start, is to clean the /tmp, /var/tmp and .cache/. Nothing to do with .config/, so why not keeping it that way? Or maybe it could be a good idea to precise that every lock files should be deleted in the "troubleshooting KDE" documentation... Your call! But for sure, it would have saved me a lot of time (like a lot of fellows that are stuck on Internet) to have that step mentioned in the documentation. Wheee: https://codereview.qt-project.org/#/c/110346/ All fixed in Qt \o/ *** Bug 346963 has been marked as a duplicate of this bug. *** Thanks! Excellent news! :o) |