[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,
either.

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