PDFsharp & MigraDoc Foundation

Hi,

I seem to be getting quite a lot of leaked memory, which i believe is to do with the way the Fonts objects work within PdfSharp. I realise this topic has been touched on previously, but after reading said topics and trying the garbage collection ideas they present, I still cant get the memory leaks to go away?

I am calling:

in quite a few places (such as at the end of the function where the Document is rendered to the PDFDocument object, and the function where i write the memorystream returned by myPdfDoc.Save()) but i still get leaks?

I have been analysing the memory usage in a tool called "ANTS Memory Profiler v6.0" and in each of my print projects, least some memory is being leaked (but is different each time) - most, if not all the leaked memory is in byte[] objects, which are references like this:
byte[] > PdfSharp.Fonts.TrueType.TrueTypeDescriptor > System.Collections.Hashtable+bucket > System.Collections.Hashtable > PdfSharp.Fonts.TrueType.FontDescriptiorStock > FontDescriptorStock.Global

I believe that this memory leak is causing IIS to crash sometimes as the leaked memory gets more and more, which is obviously not a good thing.

Hopefully someone will be able to shed some light on why this might be occurring and how i could fix it.

Thanks

Mike

p.s I think its v1.20 of PdfSharp i am using and I cant really upgrade as this is an existing product which have been "live" for some time.

Hi, Mike,

It's not a bug, it's a feature.
It's not a memory leak, it's caching.

It's on the list of issues for the next release since too much caching can be harmful.

Can be "fixed" (I mean there's a workaround for this feature) with "InternalsVisibleTo":
viewtopic.php?f=2&t=859

_________________
Regards
Thomas Hoevel
PDFsharp Team

Hi Thomas,

I have done as the other post says, i.e. added a setter for the FontDescriptorStock.Global and tried setting to null, but i was sometimes getting a "object null exception", so instead i made the Hashtable "table" in FontDescriptorStock.cs public, so i can access that and then call:

which i assume would basically do the same thing?
After the Pdf has been outputted. But i still see the byte[] objects as before in memory after i make this call?

I didnt mean to put PdfSharp down in my previous post - its a really great tool, especially as it's free! I just have a lot of client support cases to do with our production server being problematic and I was hoping that "fixing" this would solve that issue.

If the fonts are cached, presumably that means only a finite amount of memory is taken up, rather than the amount of memory taken increasing each time a pdf is created? becuase if that is the case, then the server error thing probably isnt being caused by my print code.

Thanks,

Mike