[cups.development] notifier - Get-Job-Attributes client-error-bad-request

Rodger Devine rdevine at umich.edu
Thu Apr 22 16:02:25 PDT 2010


In article <5098-cups.development at news.easysw.com>,
 Michael Sweet <msweet at apple.com> wrote:

> On Apr 21, 2010, at 11:41 AM, Rodger Devine wrote:
> > ...
> > However, I've run into a 12-byte memory leak in our notifier, which I've 
> > isolated to the following code (borrowed from lpq.c):
> 
> What is leaking the 12 bytes? When/how are you measuring for this leak?
> 
> > ...
> > Is it legal to call ippNewRequest(IPP_GET_JOB_ATTRIBUTES) and store the 
> > ipp_t pointer in the same variable as the original IPP request (event = 
> > ippNew())? 
> 
> Sure, no reason not to as long as you delete the old one (which you appear to 
> be doing).
> 
> ________________________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair

I'm using ps to monitor the virtual memory size of the notifier in bytes.

A) running before new job-state-changed event occurs:

lp        8314  0.0  0.2   6712  2448 ?        S    Apr21   0:00 
/usr/lib/cups/notifier/jnotify jnotify

B) after previous subscription event occurs:

lp        8314  0.0  0.2   6724  2460 ?        S    Apr21   0:00 
/usr/lib/cups/notifier/jnotify jnotify 

And so forth. It grew to over 20 kb after running for over a day.

However, when I remove the following lines of code after the 
cupdsDoRequest call, this increase in memory usage does *not* occur, 
which has led me to believe there's some type of leak:

       if (response->request.status.status_code > IPP_OK_CONFLICT)
       {
          fprintf(stderr, "jnotify: %s\n", cupsLastErrorString());
          ippDelete(response);
          return (0);
       }

I can email you the entire source directly (~465 lines) if my code 
snippets aren't clear.

Thanks!
Rodger




More information about the cups-devel mailing list