Memory leak in MutedRenderer::drawChar

[jwilk]

Issue reported by dmjensen7 at Google Code:

I'm using the official windows build of pdf2djvu 0.7.10 on Windows 7 64-bit. Running pdf2djvu on large files such as http://www.archive.org/download/greekenglishlex00liddrich/greekenglishlex00liddrich.pdf results in the program terminating with the message Out of memory; the exact page it terminated on changed with different settings (monochrome, resolution) but was always between 200 and 450.

Since temporary djvu files were created for each page reached before the memory error, I imagine that each page is being processed separately during the phase it's crashing in, so this would have to be some kind of leak.

[jwilk]

I have a feeling there's a memory leak somewhere indeed.

[jwilk]

With the help of gperftools' heap profiler, I identified that the MutedRenderer::drawChar method is leaking ~2 MB of memory on every page.
Traceback looks like this:

• MutedRenderer::drawChar
• SplashOutputDev::drawChar
• SplashOutputDev::doUpdateFont
• SplashFontEngine::getFont
• SplashFTFontFile::makeFont
• SplashFTFont::SplashFTFont
• FT_New_Size
• ft_mem_alloc

(MutedRenderer is pdf2djvu's own code, Splash* is in Poppler, FT_New_Size and ft_mem_alloc is in FreeType.)

Poppler's SplashOutputDev would normally quickly ignore invisible text, but pdf2djvu hacks around it to make it call doUpdateFont, so that we can get character bounding boxes. This might by why I couldn't see the same memory leak in pdftoppm.

[jwilk]

Suspiciously, Poppler calls FT_New_Size, but never FT_Done_Size.