From owner-freebsd-current@FreeBSD.ORG Sun Aug 22 22:29:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F39E16A4CE; Sun, 22 Aug 2004 22:29:17 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C71543D2D; Sun, 22 Aug 2004 22:29:17 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id A20FAFD03D; Sun, 22 Aug 2004 15:29:16 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03606-05; Sun, 22 Aug 2004 15:29:16 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 00FD7FD026; Sun, 22 Aug 2004 15:29:15 -0700 (PDT) From: Sean McNeil To: Tim Kientzle In-Reply-To: <4127841D.6050104@freebsd.org> References: <1092777586.92327.9.camel@server.mcneil.com> <20040817213813.GE3827@gothmog.gr><4127841D.6050104@freebsd.org> Content-Type: text/plain Message-Id: <1093213755.72863.0.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 22 Aug 2004 15:29:15 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: Giorgos Keramidas cc: freebsd-current@freebsd.org Subject: Re: bsdtar core dumps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 22:29:17 -0000 On Sat, 2004-08-21 at 10:19, Tim Kientzle wrote: > Sean McNeil wrote: > >>> > >>>I just tried to unarchive a file that didn't exist and got a core dump: > > > > Here is a backtrace of the error: > > > > #0 0x0000000200926d7e in __vfprintf (fp=0x7fffffffe360, > > fmt0=0x4161d9 "Failed to open '%s'", ap=0x7fffffffe640) > > at /usr/src/lib/libc/stdio/vfprintf.c:1052 > > #1 0x00000002008c4006 in vsnprintf (str=0x32
, > > n=4284889, fmt=0x4161d9 "Failed to open '%s'", ap=0x7fffffffe640) > > at /usr/src/lib/libc/stdio/vsnprintf.c:75 > > #2 0x0000000000411478 in __archive_string_vsprintf (as=0x520240, > > fmt=0x4161d9 "Failed to open '%s'", ap=0x7fffffffe640) > > at /usr/src/lib/libarchive/archive_string_sprintf.c:60 > > > > Could be a compiler bug I suppose, but more likely I think it is this > > code: > > > > if (n == 0) { > > if (on > 0) > > *str = '\0'; > > str = dummy; > > n = 1; > > } > > > > in vsnprintf.c::vsnprintf. > > The code you've pointed to above concerns > me because of the part about: > if (n == 0) { > ... > n = 1; > } > That ain't right: If I told vsnprintf the buffer > size was zero, it should treat it as such. If I > meant "one", I would have said "one." > > On the other hand, the vsnprintf.3 man page > does explicitly state that "the output is always > null-terminated," which would preclude passing > a zero-length buffer, which is exactly what > libarchive is doing in this situation. It is > bogus, but at least it's documented bogosity. ;-) > > Please try the attached patch to libarchive/archive_string_sprintf.c > and let me know if it works for you. It simply > forces the target buffer to be allocated and thereby > avoids calling vsnprintf with a NULL buffer. > > Tim Kientzle > > ______________________________________________________________________ > Index: archive_string_sprintf.c > =================================================================== > RCS file: /home/ncvs/src/lib/libarchive/archive_string_sprintf.c,v > retrieving revision 1.4 > diff -u -r1.4 archive_string_sprintf.c > --- archive_string_sprintf.c 14 Aug 2004 03:45:45 -0000 1.4 > +++ archive_string_sprintf.c 21 Aug 2004 17:02:49 -0000 > @@ -48,6 +48,9 @@ > { > size_t l; > > + /* Make sure the target area is initialized. */ > + __archive_string_ensure(as, 64); > + > if (fmt == NULL) { > as->s[0] = 0; > return; This patch didn't prevent the core dump. Cheers, Sean