| Summary: | messageviewer leaks temporary files with mail parts in it | ||
|---|---|---|---|
| Product: | [Applications] kdepim | Reporter: | Martin Steigerwald <Martin> |
| Component: | messageviewer | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | faure, montel, simonandric5, sknauss, thomas, winter |
| Priority: | NOR | ||
| Version: | GIT (master) | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kmail/1a6d1763e10e6b231fccca9b01d351c2c94b77a7 | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
Martin Steigerwald
2016-01-17 11:04:08 UTC
Almost all of the directories still have files in it: merkaba:/tmp> find -name "*unnamed*" | wc -l 116 However quite some of them are empty: merkaba:/tmp> find -name "*unnamed*" -empty | wc -l 50 merkaba:/tmp> find -name "*unnamed*" | head ./messageviewer_V24855.index./unnamed ./messageviewer_t24855.index.1/unnamed ./messageviewer_y24855.index./unnamed ./messageviewer_i24855.index.1/unnamed ./messageviewer_Z24855.index.1/unnamed ./messageviewer_o24855.index.1/unnamed ./messageviewer_J24855.index./unnamed ./messageviewer_R24855.index./unnamed ./messageviewer_p24855.index./unnamed ./messageviewer_P24855.index./unnamed […] The non empty files contain the body text of mails (even of ones without attachments). Do you have a test case when it leaks ? Because it cleans them when we switch from mail (after 10 secondes) Hm, Laurent, I clicked through some more mails and the count of messageviewer directories in /tmp didn´t increase: merkaba:/tmp> ls -ld messageviewer_* | wc -l 117 Hmmm, okay, it does when I open a mail with attachments: merkaba:/tmp> ls -ld messageviewer_* | wc -l 123 Hmmm, and indeed it cleans up: merkaba:/tmp> ls -ld messageviewer_* | wc -l 117 Okay, so now good question why it didn´t with the 117 directories in there. I have no idea yet. For me it's when kmail crash. I will look at how to clean up it during crash. Hmmm, I had some crashes when I had KMail running during kdesrc-build. But 117 files – even it at one day I had two copies of KMail run (one for work user, one for private user)? Well, I am happy to test any fix you implement from git master :). Thank you. Well I can reproduce this behaviour with a simple testcase. This one fails:
QString path;
{
NodeHelper helper;
path = helper.createTempDir(QStringLiteral("foo"));
QVERIFY(QDir(path).exists());
}
QEventLoop loop;
QTimer::singleShot(0, &loop, &QEventLoop::quit);
loop.exec();
QVERIFY(!QDir(path).exists());
if I change the singleShot to something like 11000 (11secs) if passes.
The problem here is that if the NodeHelper instance is deleted the tempfiles are deleted also only 10secs after the application and not directly with the deletion of NodeHelper. I see no need to wait 10secs when the object is already deleted.
NodeHelper::~NodeHelper()
{
//Don't delete it it will delete in class with a deleteLater;
if (mAttachmentFilesDir) {
mAttachmentFilesDir->removeTempFiles();
mAttachmentFilesDir = 0;
}
}
void AttachmentTemporaryFilesDirs::removeTempFiles()
{
QTimer::singleShot(d->mDelayRemoveAll, this, &AttachmentTemporaryFilesDirs::slotRemoveTempFiles);
}
^^ d->mDelayRemoveAll is 10secs.
I've created a patch that should improve the situation: https://phabricator.kde.org/D883 Still we have no handling, if the application crashes, but we now delete the temp dirs directly, if the object is deleted. It would be great to test it in the wild. This was fixed (for the case of cleanly quitting kmail) in c803a7a (v16.07.80). Please test. We can't do much in case of crashes -- except fixing those crashes in the first place, of course :-) I still see some messageviewer files leaked in /tmp:
messageviewer_ATD826.index.1
messageviewer_Fkk826.index.1.1
messageviewer_GzU826.index.1
messageviewer_HrO826.index.
messageviewer_JXF826.index.1
messageviewer_JhV826.index.
It seems created for every mails I open, even without attachment.
I use Kmail 5.6.0 from Archlinux.
Can we re-open the bug?
Which information should I provide to help finding the root cause?
confirmed. I have dozens of messageviewer_foo.index.1 dirs in /tmp each of them contains a file called "unnamed" Git commit 1a6d1763e10e6b231fccca9b01d351c2c94b77a7 by Montel Laurent. Committed on 01/09/2017 at 05:28. Pushed by mlaurent into branch 'master'. Fix Bug 358116 - messageviewer leaks temporary files with mail parts in it when we crash kmail too. M +21 -0 src/kmkernel.cpp M +2 -4 src/kmkernel.h https://commits.kde.org/kmail/1a6d1763e10e6b231fccca9b01d351c2c94b77a7 Wow! So efficient! Thanks Laurent But there is still a case where we can't fix, it's when you launch kmail and use CRTL+C => no crash and kmail can't delete by itself temp file. it's not possible to manage this case. But we reduce the number of temporary file. About Ctrl+C, not a big issue, but strange. Issue with catching SIGINT? About your fix, is it cleaning temp files only on crash? My issue is that these files are filling /tmp when kmail is running. Is it possible to avoid creating these files at the first place? Or could they be created in a subfolder of /tmp? (In reply to Thomas Monjalon from comment #14) > About Ctrl+C, not a big issue, but strange. Issue with catching SIGINT? > > About your fix, is it cleaning temp files only on crash? Yep and others fix was already done. > My issue is that these files are filling /tmp when kmail is running. > Is it possible to avoid creating these files at the first place? nope it's not possible as we need to extract text from message or attachement for message. > Or could they be created in a subfolder of /tmp? messageviewer_XXX is not enough ? What is the advantage to create a subfolder ? > > Or could they be created in a subfolder of /tmp? > > messageviewer_XXX is not enough ? No it's not enough because these files are never removed. So my /tmp is filling and it prevents me from seeing my new files in /tmp. > What is the advantage to create a subfolder ? The advantage is to keep /tmp clean. I use /tmp a lot and I need to keep it clean. |