Bug 150693

Summary:	kpdf tries to allocate almost all available memory.
Product:	[Unmaintained] kpdf	Reporter:	Raúl <rasasi78>
Component:	general	Assignee:	Albert Astals Cid <aacid>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	0.5.7
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Valgrind report of the crash. The patch, testing with this and lots of pdf welcome

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