Summary: | kpdf freezes the system untill it's killed by the VM | ||
---|---|---|---|
Product: | [Unmaintained] kpdf | Reporter: | DragonK <dragonk> |
Component: | general | Assignee: | Albert Astals Cid <aacid> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | The PDF causing the problems |
Description
DragonK
2006-05-17 15:53:05 UTC
Created attachment 16139 [details]
The PDF causing the problems
beware the file is bzip2ed works perfectly here, can you try reducing optimizations to a simple -O2 ? freeze != crash. Reducing severity. I can confirm the bug on my debian amd-64 system with self compiled kpdf (0.5.3). After mere seconds my machine starts to swap and top shows 400Mb in use by kpdf (400Mb res, 950Mb virt). So, if this works fine for Albert, maybe he has enough memory? Oh, it's failing at work now, i'll see if it works at home or not and try to fix it ( i should not be doing that from work ) /me hides from boss Yeah it fails here too, i'll investigate a bit Well, the problem is that the pdf requests a font of size 1400000 or something (maybe discounted at the number of 0) so obviously freetype DIES completely when trying to malloc that. Any idea on how to solve it besides limiting maximum font size to an arbitrary number? Tested again with kpdf 3.5.6, same problem. IMHO it's ok to limit the font size for ... huge values :) This works now in okular (kde-4), perhaps this bug should be closed... This does seems to work in Okular, that is the KDE 4 successor of KPDF. KPDF is no longer developed and you are encouraged to switch to Okular. If you find this does not work in Okular, please open a new bug report against it Thanks for using KDE. |