[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