Memory Leaks

[johngray1965]

With new versions of native libraries, I can't through the same tests that previously worked without native out of memory error like:

                     I  Scudo OOM: The process has exhausted 256M for size class 288.

I've been looking for places where my application might be failing to close things or leaks on the JNI wrapper (without much success). But it all works fine with older versions of native libs.

For reference, what fails is opening a large number of documents and get the text and information about the location of the text. If the document doesn't have text metadata, then it'll get bitmaps for pages.

As I write this, it occurs to me that I could separate out the files that don't have text metadata to see if issue plans only when getting the bitmaps or not (I wouldn't think just getting the text and location info would use very much memory.

[johngray1965]

It looks like it's one PDF that really causes problems. Hopefully I can figure out what about it is causing pdfium to go nuts.

[johngray1965]

I'm sure what it doesn't like about the one PDF, but if I just walk through the pages, and get each page's length, on something like the 23rd page, it goes nuts. Note I open the page, and the text page, get the length, then close the page and text page. It really feels like there's something about that page that causes the some memory issue in pdfium.

[bvitaliyg]

Hey, and thank you for the library! Is the something that occurs in the latest released version or only in the dev branch? Also, I'm a bit confused on whether this is something that happens with every large document, or only if you call each page length (which you can avoid if you only need to render it?)