Bug 693593 - resource leaks when using GSDLL32.dll gsapi_init_with_args
Summary: resource leaks when using GSDLL32.dll gsapi_init_with_args
Status: RESOLVED WORKSFORME
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library (show other bugs)
Version: 9.06
Hardware: PC Windows 7
: P4 major
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-28 08:33 UTC by Roland Weickert
Modified: 2021-02-13 20:39 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
XML-Error File from Application verifier (1.20 KB, text/xml)
2013-01-28 08:33 UTC, Roland Weickert
Details
add the test.pdf as required (11.44 KB, application/pdf)
2013-01-28 09:22 UTC, Roland Weickert
Details
A sample program that uses GS API (978 bytes, text/plain)
2021-02-13 20:38 UTC, Peter Cherepanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Weickert 2013-01-28 08:33:48 UTC
Created attachment 9253 [details]
XML-Error File from Application verifier

We try to batch-print many PDFs and encounter resource leaks after a few 1000 prints.
I investigated and found that GSDLL32.dll seems to have resouce leaks.
You  can see this after installing Microsoft Application Verifier.

Here as example:
Start Application Verifier and add gswin32c.exe to the list.

Run:
gsprint.exe Filename.pdf -printer "PDFCreator"

You will get the following application verifier log:
( See also attachment )
...
<avrf:message>Freeing heap block containing an active critical section.</avrf:message>
...

In the attachment you can see, the error in in gsdll32!+102c7cc7

Can someone have a look ?
Comment 1 Ken Sharp 2013-01-28 08:50:18 UTC
(In reply to comment #0)
> Created attachment 9253 [details]
> XML-Error File from Application verifier

Plain text would be much preferable to an XML file.

> Can someone have a look ?

Not without the original file to investigate with, no.

You don't supply a Ghostscript command line either, we need that too. As far as I  am aware, gsprint is still copyright Ghostgum Software so you may need to take this up there.
Comment 2 Roland Weickert 2013-01-28 09:22:52 UTC
Created attachment 9254 [details]
add the test.pdf as required
Comment 3 Ken Sharp 2013-01-28 09:40:39 UTC
And the Ghostscript command line ?
Comment 4 Roland Weickert 2013-01-28 10:01:28 UTC
(In reply to comment #3)
> And the Ghostscript command line ?

Hmm, I dont understand.
Do you mean the command line parameters from gswin32c.exe ?

If yes, the will not help you,
as in case of printing pdf to printer a pipe is used to pass the bitmap data to gsprint.exe


... But you simply can start 
gswin32c.exe 
and then enter QUIT
to get out 

Also in this case the Application Verifier will complain about the leaks


The problem for our company here is:
In case of many printings, we get big resource problems due to that issue.

So currently we cannot use it.

Thank you in advance.
Comment 5 Ken Sharp 2013-01-28 10:11:13 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > And the Ghostscript command line ?
> 
> Hmm, I dont understand.
> Do you mean the command line parameters from gswin32c.exe ?

Yes, we aren't equipped to debug with other applications using Ghostscript.

 
> If yes, the will not help you,
> as in case of printing pdf to printer a pipe is used to pass the bitmap data
> to gsprint.exe

Right, but if the leak is outside Ghostscript its not our problem. If it is Ghostscript then the use of a pipe should not affect the memory leak.


> ... But you simply can start 
> gswin32c.exe 
> and then enter QUIT
> to get out 
> 
> Also in this case the Application Verifier will complain about the leaks

Those are benign. We know that certain memory allocations, made once and preserved for the duration of the process, are never freed, and these show up as leaks. However these are not truly leaks, they aren't ongoing (ie the memory usage due to these allocations does not increase).

Presumably you are actually concerned about real leaks where the memory usage continues to increase.


> The problem for our company here is:
> In case of many printings, we get big resource problems due to that issue.
> 
> So currently we cannot use it.

Hmm, well you don't appear to be a supported customer of Artifex, so you must be a free user using the GPL version of Ghostscript. As you will be aware this is supplied without warranty or support.

We would like to address any memory leaks, but if you can't give us a method to reproduce the problem this is going to be difficult.
Comment 6 Roland Weickert 2013-01-28 11:35:56 UTC
Hmm,
do you want to get the test application, that shows the leaks ?

If yes, please, tellme and you get it without problem.

But you really can see the leak with gswin32c.exe in conjuction to AppVerifier.

Here you see:
The leak results of a call of 
   GSAPI_exit( instance )

To print many many files we got many many calls:

GSAPI_new_instance(...)
...
GSAPI_exit(...)
GSAPI_DELETE_Instance(...) 

Aso you see in the log-file the GSAPI_exit leaks.

And therefore we get more and more resource problems.

So this is not a benign resource leak for us.

What do you think ?

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > And the Ghostscript command line ?
> > 
> > Hmm, I dont understand.
> > Do you mean the command line parameters from gswin32c.exe ?
> 
> Yes, we aren't equipped to debug with other applications using Ghostscript.
> 
>  
> > If yes, the will not help you,
> > as in case of printing pdf to printer a pipe is used to pass the bitmap data
> > to gsprint.exe
> 
> Right, but if the leak is outside Ghostscript its not our problem. If it is
> Ghostscript then the use of a pipe should not affect the memory leak.
> 
> 
> > ... But you simply can start 
> > gswin32c.exe 
> > and then enter QUIT
> > to get out 
> > 
> > Also in this case the Application Verifier will complain about the leaks
> 
> Those are benign. We know that certain memory allocations, made once and
> preserved for the duration of the process, are never freed, and these show
> up as leaks. However these are not truly leaks, they aren't ongoing (ie the
> memory usage due to these allocations does not increase).
> 
> Presumably you are actually concerned about real leaks where the memory
> usage continues to increase.
> 
> 
> > The problem for our company here is:
> > In case of many printings, we get big resource problems due to that issue.
> > 
> > So currently we cannot use it.
> 
> Hmm, well you don't appear to be a supported customer of Artifex, so you
> must be a free user using the GPL version of Ghostscript. As you will be
> aware this is supplied without warranty or support.
> 
> We would like to address any memory leaks, but if you can't give us a method
> to reproduce the problem this is going to be difficult.
Comment 7 Ken Sharp 2013-01-28 11:56:17 UTC
(In reply to comment #6)

> do you want to get the test application, that shows the leaks ?

Personally, no, whoever gets this assigned may feel differntly.

 
> Here you see:
> The leak results of a call of 
>    GSAPI_exit( instance )
> 
> To print many many files we got many many calls:
> 
> GSAPI_new_instance(...)
> ...
> GSAPI_exit(...)
> GSAPI_DELETE_Instance(...) 

So why do you close the instance (and presumably open a new one) without exiting the process ?

As far as I'm aware the intention is that you only create one instance per process, and retain it until you close the process. However I'm no expert on the intended workings of the GSAPI interface.

Ray has done much more work than I have on 'server mode' usage of Ghostscript, which is what it sounds like you are attempting to do, so I'll leave further comment to him.
Comment 8 Peter Cherepanov 2021-02-13 20:38:17 UTC
Created attachment 20613 [details]
A sample program that uses GS API

The Visual Basic example is incorrect. At least, a similar sequence of API calls made from a C program does not work now.

There are two ways to process multiple jobs in a single invocation of Ghostscript: running a server loop, or sensational creation of multiple instances of Ghostscript. The former is more efficient, but may be difficult to reconfigure between jobs. The latter is similar to running Ghostscript as an independent process, but avoids the trouble of inter-process communication and abysmal shell scripting on Windows.

The attached sample program implements the latter approach and shows no significant memory leaks.