From owner-freebsd-bugs@FreeBSD.ORG Mon Dec 17 16:49:41 2007 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8803C16A420; Mon, 17 Dec 2007 16:49:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 183C713C458; Mon, 17 Dec 2007 16:49:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-219-213.carlnfd3.nsw.optusnet.com.au (c211-30-219-213.carlnfd3.nsw.optusnet.com.au [211.30.219.213]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id lBHGnZ8X013263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Dec 2007 03:49:37 +1100 Date: Tue, 18 Dec 2007 03:49:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: das@FreeBSD.org In-Reply-To: <200712170718.lBH7Iuoa026349@freefall.freebsd.org> Message-ID: <20071218033221.X31158@delplex.bde.org> References: <200712170718.lBH7Iuoa026349@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dan@obluda.cz, freebsd-bugs@FreeBSD.org Subject: Re: bin/83347: [patch] improper handling of malloc failures within libc's vfprintf X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 16:49:41 -0000 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