Summary: | Massive memory leak when looking at a file | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kimageformats | Reporter: | Jonas Baecker <vlu2at1ax> |
Component: | general | Assignee: | Alex Merry <alex.merry> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aacid, dreamsyntax, kdelibs-bugs, kfm-devel, mircomir, nate, nicolas.fella |
Priority: | NOR | ||
Version: | 5.113.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Head of the offending file.
Heaptrack analysis |
Description
Jonas Baecker
2024-01-10 16:12:06 UTC
Created attachment 164813 [details]
Head of the offending file.
It seems that running the file through the head command gives a file that has the same effect. Unzip and it should make Dolphin consume all of your RAM. The file is a mix file, an archive format of sorts, from a game "Tiberian Sun".
I can reproduce the issue. When generating a thumbnail for the file the memory usage of kioslave5 briefly peaks at 15GB, but goes down to normal again Created attachment 164814 [details]
Heaptrack analysis
Analyzing in heaptrack suggests the file is loaded as a TGA file. Not sure that makes sense I'm not sure there's an actual bug, the header of the file describes an image of 41039 * 63040 in size, and thus lots of memory is needed to load it to memory. You'd have to send us the actual file to confirm if it's a TGA file or not and if not if we could bail earlier. As a side thing, the QImageReader API would probably welcome a function saying "fail if we try to read a file bigger than AxB in size"? (In reply to Albert Astals Cid from comment #5) > I'm not sure there's an actual bug, the header of the file describes an > image of 41039 * 63040 in size, and thus lots of memory is needed to load it > to memory. > > You'd have to send us the actual file to confirm if it's a TGA file or not > and if not if we could bail earlier. Here's the whole file https://files.catbox.moe/fwoeqz.gz I'm using a third party filehost here as the file is too big to be attached. I can't reproduce it on Qt6, presumably because we run into the allocation limit in Qt (see https://invent.kde.org/frameworks/kimageformats/-/blob/master/src/imageformats/util_p.h?ref_type=heads#L19) For the thumbnails specifically we might be able to check the dimensions using QImageReader before trying to load the whole file and bail out if it's more than N pixels (In reply to Nicolas Fella from comment #4) > Analyzing in heaptrack suggests the file is loaded as a TGA file. Not sure > that makes sense Yeah, it's not really a TGA file. Actually, quite a few of these MIX archives are detected as TGA files for me in Dolphin, though only one of them used a lot of memory. This false detection happens with all the old Command & Conquer games that use MIX files. The games are freeware and can be downloaded from here for testing: https://cnc-comm.com/ This patch should help: https://invent.kde.org/frameworks/kimageformats/-/merge_requests/209 If I remember correctly, the thumbnail generator leaves the task of determining the correct format to the plugins (regardless of the extension and mime type). As a result, formats like TGA that do not have a unique signature can result in false positives and the plugin tries to read them. It is not a good thing. To avoid excessive RAM usage, last year I modified the thumnailer with memory checks to prevent the system from threshing. I don't know if it still works though. Also, while writing the patch for the TGA I saw that it uses double the necessary memory. This probably doesn't help either. (In reply to Mirco Miranda from comment #10) > To avoid excessive RAM usage, last year I modified the thumnailer with > memory checks to prevent the system from threshing. I don't know if it still > works though. I checked the plugin and it doesn't support options. On QT 5 therefore mitigating RAM usage is not possible. As soon as I have a moment I'll add the function to the plugin. However, with the imminent release of KDE6 there should be no problems because the Qt6 RAM limitation is correctly implemented in the plugin. (In reply to Mirco Miranda from comment #11) > I checked the plugin and it doesn't support options. On QT 5 therefore > mitigating RAM usage is not possible. As soon as I have a moment I'll add > the function to the plugin. Done. See also https://invent.kde.org/frameworks/kimageformats/-/merge_requests/212 I can confirm all Avalonia UI Desktop generated application executables result in this same issue. We believe this has been as fixed as it can be. Please upgrade to the newer versions (still unreleased) and tell us if you (ideally KDE Frameworks 6 >= 6.1 and KDE Gear >= 24.05) and tell us if you still have the problem. (In reply to Albert Astals Cid from comment #14) > We believe this has been as fixed as it can be. > > Please upgrade to the newer versions (still unreleased) and tell us if you > (ideally KDE Frameworks 6 >= 6.1 and KDE Gear >= 24.05) and tell us if you > still have the problem. I recently upgraded to Plasma 6 and can confirm that it is indeed fixed for me now. |