[PATCH] queue_new(): if calloc fails, abort (CID #57918)

Neels Hofmeyr nhofmeyr at sysmocom.de
Mon Apr 18 10:56:19 UTC 2016


On Sat, Apr 16, 2016 at 01:37:41PM +0200, Harald Welte wrote:
> Hi Neels
> 
> On Thu, Apr 14, 2016 at 04:38:42PM +0200, Neels Hofmeyr wrote:
> > Coverity complains about a 'Dereference before null check' on *queue.
> > So, push the NULL check further up, 
> 
> No question here.
> 
> > but also, instead of handling a calloc failure as error, rather abort
> > the program.
> 
> I think that's a much more fundamental question.  Should we really abort
> the program in this case?

In an in-person discussion with Holger on some other code way back some day, he
recommended to abort() on allocation failure. Might not be applicable here, of
course.

> If so, why only in case of queue allocation
> failures, but not in general at all memory allocation failures?  And if
> that's the case, wrapping calloc() / malloc() and other dynamic memory
> allocation calls with a function that contains the abort() (or an
> OSMO_ASSERT() on the result) might be more applicable?

Yes, I would agree with that.

(BTW, the only reason I didn't OSMO_ASSERT() was that there is no other use of
OSMO_ASSERT() anywhere else in OpenGGSN.)

How should we handle this, I'd prefer not to spend time on that now. Commit the
patch with `return EOF' instead of abort()ing, as the old code suggests? I
don't know about that, EOF doesn't seem applicable at all.

~Neels

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160418/cc2d932e/attachment-0001.bin>


More information about the OpenBSC mailing list