[mapserver-dev] Ticket 3559 - malloc/calloc/realloc return values should always be checked

[Daniel Morissette]

Reviving an old thread... it seems that several people were in support
of this option, but some were concerned about the proliferation of
exit() and the side-effects that they could create in some non-CGI
environments. While I would agree that spawn-fcgi is flawed if it cannot
restart aborted processes, especially in cases where a process is
running out of memory, I also believe that we could try to be more
exit-friendly in some non-fatal situations and this can be discussed
further in the context of ticket #3099.

So for the short term, it would seem to make sense to introduce the use
of msSmallMalloc(), msSmallCalloc() and msStrdup() which would exit() on
out of memory after attempting to report the error through stderr, since
there is not much we can do anyway when we're out of memory.

With respect to better handling of exit() in other situations, let's
save that for another thread.

Do we need a PSC vote before we go ahead with msSmallMalloc(),
msSmallCalloc() and msStrdup()?

What about using the names msMalloc() and msCalloc() instead and
properly documenting that they are intended for use with small
allocations only (as is done for GDAL's CPLMalloc family of functions)?

Daniel


Frank Warmerdam wrote:
> strk wrote:
>> On: Thursday, October 07, 2010 9:42 AM, Frank Warmerdam wrote:
>>
>>> I would like to propose an msSmallAlloc() function that behaves in a
>>> similar
>>> fashion, just writing an error to stderr in case of failure and calling
>>> exit().  Likewise, an msStrdup() with similar behavior.
>>
>> Better than nothing, but this will fail to be catchable by mapscript
>> or the CGI (think XML or in-image exception).
>> It's very frustrating when you get a blank image and have
>> to resort to forcing text/html content type or even worst
>> reading server logs, and there are already lots of such cases.
> 
> Strk,
> 
> Well, I can assure you that in the situation where msSmallAlloc()
> fails there would be no way of actually preparing an error report
> and burning it into an image for "inimage" error reports.  Things
> are already too desperate.
> 
> It is in fact very doubtful that we could even allocate a new
> errorObj for the error stack if we called msSetError().
> 
> To put all this in context, GDAL/OGR has always "just died" with an
> error message to stderr if small allocations fail, including when run
> in the context of applications like ArcGIS.  This has never yet, as
> far as I recall, been reported as a problem.
> 
> Best regards,


-- 
Daniel Morissette
http://www.mapgears.com/