Date: Tue, 18 Dec 2007 03:49:35 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: das@FreeBSD.org Cc: dan@obluda.cz, freebsd-bugs@FreeBSD.org Subject: Re: bin/83347: [patch] improper handling of malloc failures within libc's vfprintf Message-ID: <20071218033221.X31158@delplex.bde.org> In-Reply-To: <200712170718.lBH7Iuoa026349@freefall.freebsd.org> References: <200712170718.lBH7Iuoa026349@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Dec 2007 das@FreeBSD.org wrote: > State-Changed-Why: > If malloc fails, the program will SIGBUS on the next line anyway, so > there's no need to call abort(). This situation can only arise if the > programmer has asked printf() to handle a very long and bizarre series > of positional arguments after exhausting all available virtual memory, > so hopefully this won't be a big deal. Er, printf() is not permitted to either dump core or call abort() due to resource shortages. This is handled correctly in __wcsconv() -- __wcsconv() uses malloc() only internally and returns NULL on malloc failure; it can fail for other reasons and all failures become error returns for _vfprintf(). This is handled incorrectly by the horrible arg table extension. It aborts on malloc failure in 2 cases (on actually reallocf) and follows the null pointer in one other case. I prefer following the NULL pointer to aborting. It gives core dumps that aren't messed up by abort()'s frames and doesn't waste space doing wrong error handling. Anyway, malloc() never ;-) fails, and when it does misconfigured MALLOC_OPTIONS (with A) often breaks precisely the programs that actually handle malloc failure correctly; in vfprintf it just makes the broken code more unreachable than with malloc "never" failing. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071218033221.X31158>