Bug 150693 - kpdf tries to allocate almost all available memory.
Summary: kpdf tries to allocate almost all available memory.
Status: RESOLVED FIXED
Alias: None
Product: kpdf
Classification: Applications
Component: general (show other bugs)
Version: 0.5.7
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Albert Astals Cid
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-11 01:37 UTC by Raúl
Modified: 2007-10-22 22:34 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Valgrind report of the crash. (14.05 KB, text/plain)
2007-10-11 09:50 UTC, Raúl
Details
The patch, testing with this and lots of pdf welcome (11.78 KB, patch)
2007-10-19 22:43 UTC, Albert Astals Cid
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Raúl 2007-10-11 01:37:55 UTC
Version:           0.5.7 (using KDE 3.5.7, Debian Package 4:3.5.7.dfsg.1-7 (lenny/sid))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.22rs

Try this command:
kpdf http://www.blusens.com/trabajo/Project_Support.pdf

You will experience a very high memory consumption, almost all your available memory will be allocated, get the system into hard swap state.

I will provide more info as soon as I can.
Comment 1 Raúl 2007-10-11 09:50:24 UTC
Created attachment 21791 [details]
Valgrind report of the crash.

This has been the valgrind command line: valgrind --tool=memcheck
--leak-check=full --log-file=kpdf kpdf test.pdf

And the command line output:
keditbookmarks: WARNING: KBookmarkManager::findByAddress: couldn't find item /1

Bogus memory allocation size

valgrind --show-reachable=yes parameter output can be send on request.
Comment 2 Albert Astals Cid 2007-10-14 22:11:29 UTC
Hi, actually the pdf is broken and that's what causes us to use so much memory, i have a patch in the pipeline that makes kpdf able to cope with such brokeness but it needs some more testing. Thanks for reporting.
Comment 3 Raúl 2007-10-15 08:27:30 UTC
Thanks for the feedback. I suspected that there was anything wrong since I've never had such a problem with kpdf, the only thing makes me doubt about this is that kghostscript was able to open it.

Please let me know if I could be of any help/test anything.

Thanks.
Comment 4 Albert Astals Cid 2007-10-19 22:43:08 UTC
Created attachment 21867 [details]
The patch, testing with this and lots of pdf welcome
Comment 5 Albert Astals Cid 2007-10-22 22:34:42 UTC
SVN commit 728256 by aacid:

Splash rework, check if font is inside clip area before rendering it to a temporary bitmap. Fixes bug 150693
This change is not trivial. What i did is:
It is getGlyph the one that does the intersection between clip area and rendering area of the font instead fillGlyph2
That means some clipRes = state->clip->testRect but we win more robustness against broken pdf that specify HUGE fonts

BUG: 150693


 M  +19 -0     goo/gmem.cc  
 M  +1 -0      goo/gmem.h  
 M  +17 -20    splash/Splash.cc  
 M  +2 -2      splash/Splash.h  
 M  +21 -3     splash/SplashFTFont.cc  
 M  +2 -2      splash/SplashFTFont.h  
 M  +23 -6     splash/SplashFont.cc  
 M  +3 -2      splash/SplashFont.h  
 M  +8 -3      splash/SplashT1Font.cc  
 M  +2 -2      splash/SplashT1Font.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=728256