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:
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.
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.
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.
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.
Created attachment 21867 [details]
The patch, testing with this and lots of pdf welcome
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
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