2

The project I'm on is using a 3rd party component to build dynamic PDFs in a VB.Net web system called ABCpdf.Net. (not a terrible tool, but not a great one either.)

Every now and then, for reasons I can't fathom, the document object throws a SEHException. Digging futher, it turns out this is caused by a custom exception in the document object of the type WebSupergoo.ABCpdf6.Internal.PDFException. The contents contains only the not -terribly-helpful title "Unable to get image data. Out Of Memory" Usually this happens when trying to add an image to the PDF. Since these images are PNGs of less than 100k, I'm guessing their size isn't the issue.

Also, the really strange thing is that once this issue starts happening, the only way to get it to stop seems to be to reboot the web server, which is clearly a little sub-par.

Has anyone ever had this problem (or even used this tool?)

Electrons_Ahoy
  • 36,743
  • 36
  • 104
  • 127

3 Answers3

2

Fascinating. I had come to the conclusion that was what must be going on. Do you still call the doc.Clear() at the end of the using block?

Electrons_Ahoy
  • 36,743
  • 36
  • 104
  • 127
  • I do not as I believe that the dispose method of Doc handles that for you. – Craig Wilson Oct 06 '08 at 22:23
  • Out of curiosity I ran a disassembler on my copy of the ABCpdf 7 .NET assembly. Dispose() definitely cleans up a number of things that Clear() does not (e.g. mObjects, mEncryption, mTransform). It seems likely that Clear() is redundant if you call Dispose(), but I'm not 100% sure. (It depends on whether or not WebSupergoo.ABCpdf7.Internal.NDoc.Clear does any cleanup beyond what WebSupergoo.ABCpdf7.Internal.NDoc.Delete does. I'd guess no, but I think you'd have to crack open the non-managed code to find out for sure.) – Chris Oct 19 '11 at 20:47
  • 1
    I also wrote Websupergoo tech support to get clearer about Doc.Clear. They explained that Doc is a normal .NET IDisposable, and you should treat it as such, e.g. by putting it in a using block. (I asked about ver 7, but I assume this is true going forward as well.) Doc.Clear "is only really relevant if you are going to want to re-use the Doc at some point in the future". – Chris Oct 20 '11 at 08:29
2

Update, three months later:

As near as I can tell, the memory issues were all resolved when we upgraded from ABCpdf 6 to 7. It would seem that version 7 is no longer a COM object with a .NET wrapper, but all managed code from the bottom up. It's still not the greatest PDF generator out there, but the resource disposal problems seem to have been resolved.

Electrons_Ahoy
  • 36,743
  • 36
  • 104
  • 127
  • 2
    This is nit-picking, but I'm pretty confident that ABCpdf 7 is still _not_ "all managed code". In particular, there's a core ABCpdfCE7.dll (which gets installed in C:\Windows\System32), which appears _not_ to be managed code (e.g. If you try to run .NET's corflags util on it, corflags reports "The specified file does not have a valid managed header".), and that gets wrapped by the ABCpdf.dll .NET assembly. The latter assembly does seem to be "pure .NET", and not depending on COM, which is nice. (Or if it does depend on COM somehow, it hides all the details from you.) – Chris Oct 19 '11 at 19:08
  • @Chris - yeah, that sounds about right. Still, either the COM is gone or hidden far enough down that it no longer matters. Either way, I stopped having to reboot the web server once a week after the upgrade. – Electrons_Ahoy Oct 19 '11 at 20:21
1

I haven't specifically seen this error before, but we've had memory issues with ABC PDF before.

Long story short is that it is NOT a completely managed code base, but simply a .NET wrapper around their COM version. That being said, we traced our memory usage problem to not disposing of their objects properly.

So, instead of:


Dim doc As New Doc()
'etc...

do this:


    Dim doc as Doc
    Using doc As New Doc()
      'etc...
    End Using
Craig Wilson
  • 12,174
  • 3
  • 41
  • 45
  • so what if it isn't 100% pure managed? It implements IDisposable, you didn't dispose it. Fault's yours, you should know .NET requires careful object lifetime management. – gbjbaanb Oct 06 '08 at 21:56
  • I wasn't blaming ABC PDF. "We did not dispose of their objects properly". But, not disposing of managed resources can have a different effect than not disposing of unmanaged resources, and the effect here is that ABC PDF begins to fail. – Craig Wilson Oct 06 '08 at 22:41
  • 1
    It's also worth pointing out that the ABCpdf documentation doesn't say that it implements IDisposable, and in fact more or less states you *don't* need to dispose of the Doc object. – Electrons_Ahoy Oct 07 '08 at 00:24