Version: 2.14 (using KDE 4.4.4) OS: Linux Ark pwns the desktop and silently dies trying to preview a large file. Reproducible: Always Steps to Reproduce: 1. Tell Ark to open the file <URL:http://ftp.mozilla.org/pub/mozilla.org/data/reporter.mozilla.org/reporter_mozilla_org_anonymized.sql.gz> 2. Tell Ark to preview file reporter_mozilla_org_anonymized.sql. Actual Results: 1. The archive contains the file reporter_mozilla_org_anonymized.sql 2. The desktop stops responding for a while until Ark silently dies. Expected Results: 2. Ark cannot preview this file because it is too large. Would you like to extract it instead? OS: Linux (x86_64) release 2.6.34.7-0.5-desktop Compiler: gcc
Hmm... Ark does not die here, it just takes a long time for KatePart to load the 1GB file and display it (it did crash when I closed it, though). I'm not sure what to do here -- there could be a GUI for setting the maximum size of the files Ark should preview, but currently we don't have the uncompressed size for some formats (such as .gz).
How about physical RAM / 2? In cases Ark is unable to determine the uncompressed size, it should intervene after uncompressing. For it is better to refuse to launch the previewer than to hit the host machine out of service.
(Physical RAM / 2) sounds quite arbitrary, and the amount of available RAM (which isn't easy to obtain in an accurate way) at the moment might be quite low already. Ideally, KatePart should work better or ask about this itself.
Should this bug be reassigned to Kate then? I do not think so. Ark, being the hosting application, is responsible for the plug-ins that it uses. If a plug-in is unstable, Ark should not use it, or use it with caution so that it does not cause problems. Of course, it does not mean that Kate should not be fixed, but do not expect me to file a bug against Kate because I do not have insight into how the KatePart is used within Ark.
(In reply to comment #4) > Should this bug be reassigned to Kate then? I do not think so. > Ark, being the hosting application, is responsible for the plug-ins that it > uses. If a plug-in is unstable, Ark should not use it, or use it with caution > so that it does not cause problems. The whole idea of using KParts is that the "hosting" application should not be aware of the KPart it is actually using -- there's nothing in the code that detects that it is KatePart that is being used. So Ark cannot be responsible for the plug-ins it uses, in that sense. > Of course, it does not mean that Kate should not be fixed, but do not expect me > to file a bug against Kate because I do not have insight into how the KatePart > is used within Ark. Had I expected you to just file a bug against Kate, I'd have already closed this report or reassigned it ;) I'm keeping the report open until I have a more solid opinion on what path to take. Showing a warning before previewing a large file sounds like a good idea, but implementing it is the tricky part. Plus, if we strictly follow this logic, KDE itself should show a warning whenever you try to open a big file (since Ark is essentially just launching Kate), which does not make much sense IMO.
(In reply to comment #5) > The whole idea of using KParts is that the "hosting" application should not be > aware of the KPart it is actually using -- there's nothing in the code that > detects that it is KatePart that is being used. So Ark cannot be responsible > for the plug-ins it uses, in that sense. If Ark starts a child process and the child process crashes, you can happily point your finger at it screaming "Stop thief!". However, if you allow unshielded third-party code into Ark and it crashes, you can do nothing because you are dead, and you are to blame.
Ark now allows configuring an upper size limit for preview of files (set to 200MB by default). However, the linked file in this bug report is a single gzipped file and the singlefileplugin doesn't support showing size of files, and hence the preview size limit doesn't have any effect for this archive.