PDFsharp & MigraDoc Foundation

Hi,

Does anyone know why my memory usage on w3wp.exe (the application pool's process) keeps going up and up and NEVER goes down?

I have tested this with the bare minimum of content in a PDF (just display "Hi" on 1 page) and when i repretdly run the same code, the memory usage keeps going up every time. If this was a caching thing, the cache would be reusing some of the objects (especially the fonts) and therefore not consuming more memory. Also, if it was caching, then the cached objects should clear after 30 seconds (as that is the IIS cache period i believe) but it doesnt, just sits at whatever amount of memory it was using when the pdf was outputted forever!

I have tested this with PdfSharp/MigraDoc 1.2 and 1.31 - both GDI+ and WPF builds and it behaves the same in each situation.

I have also implemented the FontDataStock.Global = null "fix" Thomas Hoevel mentioned in another post, but the collection stored within the Global property was empty anyway...

I do not know what to do and I have very heavy usage of my code which is causing the occasional "Page Cannot be found" or if I remove the recycle settings on the application pool, I get Out of Memory errors after about 10 prints.

I have invested quite a lot of time building many print routines using this great library and this is the first time I have come accross a problem this serious - its only an issue becuase of the number of users generating PDFs, which makes the memory usage go up so rapidly. But as we have 15000 live users, you can see why it might be an issue.

PLEASE HELP ME!

Thanks,

Mike

Hi, Mike,

I informed my boss about your observation.
We'll investigate that.

_________________
Regards
Thomas Hoevel
PDFsharp Team

Hi Thomas,

I actually had a bit of a break through this morning and have "fixed" the primary issue i was having, so the memory is only increasing by a much smaller amount each time now, so the problem is less of an issue for the time being, but its still there.

If its any help, I have changed my code to load fonts into a singleton class (as I have a class which chooses a font to use based on the text being added to the pdf for multilingual applications) and never destroying the singleton until the app pool is recycled. Previously I was creating a new FontSearcher for each print (even though it was the same fonts used each time and I know for sure the FontSearcher class wasnt leaking) it was dramatically increasing, whereas now it once does it only once, so the memory increase each time is minimal.

It was still "leaking" memory or whatever when i test pdfsharp/migradoc standalone without any of my code sitting on top in the little "Hi" tests i mentioned though...

Good to know its being investigated.

Thanks,

Mike

Have you tried attaching to the w3wp app pool in the debugger and tried using !dumpheap -stat and !gcroot with -min/-max /-type options to narrow down what kinds of objects are being left around?

Since you can repro some of this locally, maybe try your simple app that creates the document, then set the pdfdocument (or other root object) variable to null, force GC, then look at what's left in the heap using the above?

Also, RedGate has a pretty decent mem profiler you can try out for free that might shed some light also.

Just trying to help.. Very interested in your results btw...

-Jeff