[cups.development] malloc without NULL check

Michael Sweet mike at easysw.com
Mon May 26 06:34:35 PDT 2008

Jon Peatfield wrote:
> On Sat, 24 May 2008, Michael Sweet wrote:
>> andreas moroder wrote:
>>> ...
>>> and more in other places in cups-1.4svn-r7613
>> First, a NULL will just cause the filter to crash, stopping the job.
>> Second, if malloc() fails there is nothing we'll be able to do other
>> than exit with a non-zero exit status, stopping the job.
> It could 'hold' (or delay?) the job(s) and/or log a message perhaps 

There is no way for a filter to hold the job, only to stop the queue.
A failing filter does stop the job (which can be restarted later)...

> explaining how much memory had been allocated (so far) and how much was 
> being requested when it ran out...

Memory usage is not something that is available via POSIX or C API,
and saying "unable to allocated 10000 bytes" is not very useful,

It might be worthwhile to provide some sort of API that can invoke
an OS-specific traceback on allocation and other failures.

> If multiple jobs are being processed at the same time it might be that 
> the job would have succeeded if there had been fewer allowed to run.
 > ...

I suspect that if memory is an issue then the processes will not be
able to run in the first place - the initial fork() creates a copy
of cupsd's memory space, and the OS has to reserve at least that
much memory (even if it doesn't do a copy...)  Only the image filters
might allocate substantially more memory than cupsd, and even they are
limited by the RIPCache setting (8M by default)...

Michael Sweet, Easy Software Products           mike at easysw dot com

More information about the cups mailing list