From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 5 17:56:02 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E1E3106564A for ; Sun, 5 Jul 2009 17:56:02 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by mx1.freebsd.org (Postfix) with ESMTP id 06F7A8FC0C for ; Sun, 5 Jul 2009 17:56:01 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz17 with SMTP id 17so94138bwz.43 for ; Sun, 05 Jul 2009 10:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jlf0nqTWsh5xfxoyelYdAurYVJZz9PAvYq2s7PjqrsI=; b=xsH+Mvfog/8maPz2OrSwz5JmEDqiXTamZds5s3rl9fnv5C0pP6NTSMdtnxrTuIV9Zt HHPGf3IuWGMyiNEWwOhvC4N73SFzRSviSH0W8899egDQhoWFuG1zeu4a35hRyoiECQXk +Zx7G7ymTmg5/WQq2ev+sDxLwE6YhzCoMdn3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=olZqXDFk8A8OUMwWDTie07Hf73pMhADUVhqRPQlJ+Bsvs+7fqqAeUyfplZ/JRh79MP SPojG8sJV1I8gOkxZf7ia7roFD6UdYsmv2ZetIv9dgfrOLPXKlbXwJfxx7EL9PUeXXJ9 FTv/5GPnS2RQ/7llzWdX+CnIMBCj+CTJGbHEI= MIME-Version: 1.0 Received: by 10.204.71.65 with SMTP id g1mr3710459bkj.27.1246816560869; Sun, 05 Jul 2009 10:56:00 -0700 (PDT) In-Reply-To: <20090705182856.799b6b07@fabiankeil.de> References: <20090705182856.799b6b07@fabiankeil.de> Date: Sun, 5 Jul 2009 17:56:00 +0000 Message-ID: <3a142e750907051056n2e1424erfb6ed75b0bb94ed2@mail.gmail.com> From: "Paul B. Mahol" To: Fabian Keil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Zero-length allocation with posix_memalign() X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 17:56:02 -0000 On 7/5/09, Fabian Keil wrote: > I recently submitted a patch to the vlc developers that prevents > a crash on FreeBSD 8.0 by not calling posix_memalign() with a > size argument of zero. > > A simplified test case would be: > > #include > int main(int argc, char **argv) { > void *ptr; > posix_memalign(&ptr, 16, 0); > return (0); > } > > which triggers: > Assertion failed: (size != 0), function arena_malloc, file > /usr/src/lib/libc/stdlib/malloc.c, line 3349. Actually that assertion is triggered only if MALLOC_PRODUCTION is undefined. (when it is undefined it considerably slows thing down) 'a' flag for malloc.conf looks broken for me .... > > Remi Denis-Courmont, one of the vlc developers, pointed out > that passing a zero size to posix_memalign() should actually > work, though: > > | In principle, while useless, there is no reason why allocating an empty > | picture should not be possible. posix_memalign() does support zero-length > | allocation anyway: > | > http://www.opengroup.org/onlinepubs/9699919799/functions/posix_memalign.html > | | If the size of the space requested is 0, the behavior is > | | implementation-defined; the value returned in memptr shall be either a > | | null pointer or a unique pointer. > http://mailman.videolan.org/pipermail/vlc-devel/2009-July/062299.html > > I get the impression that this deviation from the standard could be > easily fixed with something similar to the following, which is mostly > copy and pasted from malloc(): > > index 5404798..a078d07 100644 > --- a/malloc.c > +++ b/malloc.c > @@ -5303,6 +5303,15 @@ posix_memalign(void **memptr, size_t alignment, > size_t size) > int ret; > void *result; > > + if (size == 0) { > + if (opt_sysv == false) > + size = 1; > + else { > + ret = 0; > + *memptr = result = NULL; > + goto RETURN; > + } > + } > if (malloc_init()) > result = NULL; > else { > > I assume the "goto RETURN" isn't entirely compliant either as > it skips the alignment check, but so does the malloc_init() > failure branch. > > Fabian > -- Paul