[poppler] pdftotext (0.24.5 version) - Memory Leak

[Jason Crain]

On 2014-03-19 07:20, Marco wrote:
> I have check any memory leak with valgrind and original pdftotext
> (poppler-0.24.5) because using its code in my program that converts a
> sequence of pdf files in text format, Ive seen that takes too much
> system memory.
>
> For test I have used a pdf file (it had inside only ONE WORD) with
> command valgrind -v --tool=memcheck --leak-check=full
> --show-reachable=yes --track-origins=yes ./pdftotext -bbox
> /tmp/file.pdf - 2>/tmp/valgrind.log >> /tmp/valgrind.log and in 
> return
> briefly this result:
>
> ==11606== LEAK SUMMARY:
> ==11606==    definitely lost: 24 bytes in 1 blocks
> ==11606==    indirectly lost: 0 bytes in 0 blocks
> ==11606==      possibly lost: 0 bytes in 0 blocks
> ==11606==    still reachable: 22,311 bytes in 740 blocks
>  ==11606==         suppressed: 0 bytes in 0 blocks
> ==11606==
> ==11606== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from
> 0)
> --
> ==11607== LEAK SUMMARY:
> ==11607==    definitely lost: 34 bytes in 1 blocks
>  ==11607==    indirectly lost: 0 bytes in 0 blocks
> ==11607==      possibly lost: 0 bytes in 0 blocks
> ==11607==    still reachable: 21,247 bytes in 694 blocks
> ==11607==         suppressed: 0 bytes in 0 blocks
> ==11607==
>  ==11607== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 
> from
> 0)
> --
> ==11609== LEAK SUMMARY:
> ==11609==    definitely lost: 14 bytes in 1 blocks
> ==11609==    indirectly lost: 0 bytes in 0 blocks
> ==11609==      possibly lost: 0 bytes in 0 blocks
>  ==11609==    still reachable: 46,029 bytes in 2,147 blocks
> ==11609==         suppressed: 0 bytes in 0 blocks
> ==11609==
> ==11609== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from
> 0)
> --
>
> Im not expert programmer but in this case log of valgrind like this:
>
> ==11606== 1,600 bytes in 1 blocks are still reachable in loss record
> 523 of 524
>  ==11606==    at 0x4007D89: malloc (vg_replace_malloc.c:236)
> ==11606==    by 0x80AE501: xmalloc (in /bin/bash)
> ==11606==    by 0x524F4C4E: ???
> ==11606==
> ==11606== 3,163 bytes in 51 blocks are still reachable in loss record
> 524 of 524
>  ==11606==    at 0x4007D89: malloc (vg_replace_malloc.c:236)
> ==11606==    by 0x80AE501: xmalloc (in /bin/bash)
> ==11606==    by 0x807925A: ??? (in /bin/bash)
> ==11606==    by 0x807C12C: maybe_make_export_env (in /bin/bash)
>  ==11606==    by 0x808D2C4: command_substitute (in /bin/bash)
> ==11606==    by 0x80931B9: ??? (in /bin/bash)
> ==11606==    by 0x809431C: ??? (in /bin/bash)
> ==11606==    by 0x80946C8: expand_word_unsplit (in /bin/bash)
>  ==11606==    by 0x8077B6C: ??? (in /bin/bash)
> ==11606==    by 0x80741D4: execute_command_internal (in /bin/bash)
> ==11606==    by 0x8077A21: execute_command (in /bin/bash)
> ==11606==    by 0x8077FA4: ??? (in /bin/bash)
>
> are incomprehensible for me and despite all my goodwill Im not able 
> to
> understand where to find code that cause memory leak.
>
> Unfortunately, the excessive use of memory does not allow to utilize
> code for the intensive uses.

Are you sure you are testing the right executable?  That looks like you 
are running valgrind on bash.  Make sure pdftotext isn't a shell script.