EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Memoryleaks when signing an already signed pdf

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#23493
Posted: 02/18/2013 04:26:53
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 73

I'm writing a service application that signs pdf documents that are already signed. Because the service should run for a long time without restarting I want to eliminate all memory leaks that increase with each signing.

I noticed that signing a pdf without signatures goes without problems. However, if the pdf already contains a signature a rather large memoryleak is left behind by SBPDF.GetSignatureSecurityHandler. The TElPDFSecurityHandler instance that is created here is not freed after the document is closed, so for each document that is signed a new TElPDFSecurityHandler leaks (which creates quite a lot of sub-objects). I think the TElPDFSecurityHandler becomes part of the document signature so there is no reason that it should be left behind when the document is closed and the signature is freed.

I also checked this behaviour with the TinySigner example. If I modify the example so that a document is signed mutiple times the leaked memory increases.

Please advise how to fix this behaviour.
#23494
Posted: 02/18/2013 04:32:05
by Vsevolod Ievgiienko (EldoS Corp.)

Hello.

Please refer to this docs page: http://www.eldos.com/documentation/sb...dlers.html

Quote
Note, that user should take care of disposal of all security handlers, no matter what the value of ActivateSecurityHandlers is.
#23497
Posted: 02/18/2013 04:58:47
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 73

Thanks for pointing that out. I now check all the signature handlers and if they are different from the handler that I created I assume they are 'auto-created' and free them. That solves the leaking of TElPDFSecurityHandlers.

All that is left now is an increasing leak of TElPDFByteRange, I'll see if I can find where that originates from.

Once again thank you for the quick response.
#23498
Posted: 02/18/2013 05:01:56
by Vsevolod Ievgiienko (EldoS Corp.)

Quote
All that is left now is an increasing leak of TElPDFByteRange, I'll see if I can find where that originates from.

Please let us know the details. We'll check if any fix should be done.
#23499
Posted: 02/18/2013 05:17:24
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 73

To reproduce modify the TinySigner example. MainFrom.pas on line 604.
After:

Code
// closing the document
Document.Close(Success);

Add:
Code
for I := 0 to Document.SignatureCount - 1 do
  if Assigned(Document.Signatures[i].Handler) and (Document.Signatures[i].Handler <> PublicKeyHandler) then
    Document.Signatures[i].Handler.Free;

(And declare I: Integer).

Sign a simple pdf file and take note of the memoryleaks after closing (ReportMemoryLeaksOnShutdown := True), especially:

Code
13 - 20 bytes: TList x 16


Run again and sign the already signed pdf for a 2nd time. Notice all memoryleaks are the same except for:

Code
13 - 20 bytes: TElPDFByteRange x 2, TList x 16


If you disable the Close and sign the same document multiple times each signing adds another two instances of TElPDFByteRange to the leaks.
#23501
Posted: 02/18/2013 05:56:18
by Birger Jansen (Standard support level)
Joined: 07/19/2012
Posts: 73

I think that this change fixes this memory leak:

Code
destructor TElPDFSignature.Destroy;
begin
  ClearSigRefEntries;
  FreeAndNil(FSigRefEntries);
  ClearByteRanges;                 //<------ this line is new
  FreeAndNil(FByteRanges);
  FreeAndNil(FWidgetProps);
  inherited;
end;

Can you confirm that this doesn't break anything else?
#23502
Posted: 02/18/2013 06:06:50
by Dmytro Bogatskyy (EldoS Corp.)

Quote

Code
13 - 20 bytes: TElPDFByteRange x 2

If you disable the Close and sign the same document multiple times each signing adds another two instances of TElPDFByteRange to the leaks.

It is fixed for the next build.
Thank you for pointing this out.
#23503
Posted: 02/18/2013 06:08:21
by Dmytro Bogatskyy (EldoS Corp.)

Quote
Can you confirm that this doesn't break anything else?

Yes, it is a correct fix. Thank you.
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

Topic viewed 649 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!