Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 15340 invoked from network); 29 Sep 2009 18:55:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Sep 2009 18:55:41 -0000 Received: (qmail 99841 invoked by uid 500); 29 Sep 2009 18:55:41 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 99742 invoked by uid 500); 29 Sep 2009 18:55:40 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 99734 invoked by uid 99); 29 Sep 2009 18:55:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Sep 2009 18:55:40 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of trawick@gmail.com designates 72.14.220.152 as permitted sender) Received: from [72.14.220.152] (HELO fg-out-1718.google.com) (72.14.220.152) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Sep 2009 18:55:32 +0000 Received: by fg-out-1718.google.com with SMTP id e21so1042322fga.13 for ; Tue, 29 Sep 2009 11:55:11 -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:content-type; bh=LKytGyoR5RI5x/NHmIGGJJjZ6KzEyqymV0I6X2CbaC8=; b=WFMmzxbS8xbnovJ6H1tkxWL2HePa/IzvpHvOntkceJIbckBAtzrZpMCzfFtswHt9St I+nOhXH2XcKLQ4g3kTBBQhUUnBCPfvKG3Z5NYPhlmf8VzcuVFZ4I8ipDP4htqZYp4a92 pFf6138wQd9gRFZWyXgKHHXhx/7PenI5/MEr8= 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 :content-type; b=FAI/XaqlDeAW9tAdlg3/7si63U5zU/ZaOGnrIl2qi+je7MAz2HhTSHCW2T+t7N1Chd cDpwv6dS4kNpCRJDCBXmjCyO2HEBqwScMQ/BW+dw+66UVjdAIWZgIZ/tYk+mCHdETztM KUZ0e0C/vqVrjFUzf9gDrXU2FffADBHCNxmfg= MIME-Version: 1.0 Received: by 10.86.227.1 with SMTP id z1mr4498830fgg.56.1254250511236; Tue, 29 Sep 2009 11:55:11 -0700 (PDT) In-Reply-To: References: <4AB7FD44.4080205@sharp.fm> Date: Tue, 29 Sep 2009 14:55:11 -0400 Message-ID: Subject: Re: [vote] release apr 1.3.9? From: Jeff Trawick To: APR Developer List Content-Type: multipart/alternative; boundary=001485ea0ff42e7dee0474bbf486 X-Virus-Checked: Checked by ClamAV on apache.org --001485ea0ff42e7dee0474bbf486 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 22, 2009 at 1:41 PM, Jeff Trawick wrote: > On Tue, Sep 22, 2009 at 11:33 AM, Jeff Trawick wrote: > >> On Tue, Sep 22, 2009 at 11:10 AM, Jeff Trawick wrote: >> >>> On Mon, Sep 21, 2009 at 6:25 PM, Graham Leggett wrote: >>> >>>> Hi all, >>>> >>>> I have rolled a candidate of apr v1.3.9 and propose it for release, >>>> available here: >>>> >>>> http://people.apache.org/~minfrin/apr/ >>>> >>>> >>> +1 >>> (Mac OS X 10.5.8 on x86, 32-bit testing only, OpenSolaris 2009.06 + >>> SunStudio on x86, 32-bit and 64-bit testing) >>> >>> I get a crash in testhash with the 64-bit OpenSolaris build, but that >>> happens with 1.3.8 as well :( >>> >>> >> In case somebody wonders: >> >> t@1 (l@1) program terminated by signal SEGV (no mapping at the fault >> address) >> Current function is apr_vformatter >> 954 s = va_arg(ap, char *); >> > > To this very naive observer, it looks like a compiler bug (Sun Studio 12 > Update 1). Some overflow area processing has been triggered since we've > gone beyond 0x30 bytes of arguments. The address into the overflow area > gets whacked at the 32-bit mark and va_arg() dies trying to use it. > In case anybody sees this post and wonders if they should be worried: As far as I can tell, it occurs only with "-O0", as in "cc -m64 -O0 -g foo.c" so other people aren't likely to encounter it. I've only tested on x86. A simple non-APR testcase is #include #include #include #include static void local_vformatter(char *buf, size_t len, const char *format, va_list ap) { char *str; ssize_t bigval; str = va_arg(ap, char *); printf("arg %s\n", str); str = va_arg(ap, char *); printf("arg %s\n", str); bigval = va_arg(ap, /* ssize_t */ unsigned long); printf("arg %lld\n", bigval); str = va_arg(ap, char *); printf("arg %s\n", str); } static void local_snprintf(char *buf, size_t len, const char *format, ...) { va_list ap; va_start(ap, format); local_vformatter(buf, len, format, ap); va_end(ap); } int main(void) { char buf[800]; char *key, *val; ssize_t len; key = "KEY1"; val = "VAL1"; len = strlen(key); local_snprintf(buf, sizeof buf, "%sKey %s (%ld) Value %s\n", "->", key, len, val); /* printf(buf); */ } No crash with Sun Studio 12 (no update) on Solaris 10 U5. --001485ea0ff42e7dee0474bbf486 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 22, 2009 at 1:41 PM, Jeff Trawick <trawick@gmail.com<= /a>> wrote:
On Tue, Sep 22, 2009 at 11:33 = AM, Jeff Trawick <trawick@gmail.com> wrote:
On Tue, Sep 22, 2009 at 11:= 10 AM, Jeff Trawick <trawick@gmail.com> wrote:
On Mon, Sep 21, 2009 at 6:25 PM, Graham Leg= gett <minfrin@sharp.fm> wrote:
Hi all,

I have rolled a candidate of apr v1.3.9 and propose it for release,
available here:

http= ://people.apache.org/~minfrin/apr/


+1
(Mac OS X 10.5.8 on x86, 32-bit testi= ng only, OpenSolaris 2009.06 + SunStudio on x86, 32-bit and 64-bit testing)=

I get a crash in testhash with the 64-bit OpenSolaris build= , but that happens with 1.3.8 as well :(


In case somebody wonders:

t@1 (l@= 1) program terminated by signal SEGV (no mapping at the fault address)
C= urrent function is apr_vformatter
=A0 954=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 s =3D va_arg(ap, char *);

To this very naive observer, it looks like a co= mpiler bug (Sun Studio 12 Update 1).=A0 Some overflow area processing has b= een triggered since we've gone beyond 0x30 bytes of arguments.=A0 The a= ddress into the overflow area gets whacked at the 32-bit mark and va_arg()= dies trying to use it.

In case anybody sees this post and wonde= rs if they should be worried:

As far as I can tell, it occurs only w= ith "-O0", as in "cc -m64 -O0 -g foo.c" so other people= aren't likely to encounter it.=A0 I've only tested on x86.

A simple non-APR testcase is

#include <stdarg.h>
#inclu= de <stdio.h>
#include <stdlib.h>
#include <string.h>= ;

static void local_vformatter(char *buf, size_t len,
=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= const char *format, va_list ap)
{
=A0=A0=A0 char *str;
=A0=A0=A0 ssize_t bigval;

=A0=A0=A0 str= =3D va_arg(ap, char *);
=A0=A0=A0 printf("arg %s\n", str);
=A0=A0=A0 str =3D va_arg(ap, char *);
=A0=A0=A0 printf("arg %s= \n", str);

=A0=A0=A0 bigval =3D va_arg(ap, /* ssize_t */=A0 uns= igned long);
=A0=A0=A0 printf("arg %lld\n", bigval);

=A0=A0=A0 str =3D = va_arg(ap, char *);
=A0=A0=A0 printf("arg %s\n", str);
}
static void local_snprintf(char *buf, size_t len,
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 const char = *format, ...)
{
=A0=A0=A0 va_list ap;

=A0=A0=A0 va_start(ap, format);
=A0=A0= =A0 local_vformatter(buf, len, format, ap);
=A0=A0=A0 va_end(ap);
}
int main(void)
{
=A0=A0=A0 char buf[800];
=A0=A0=A0 char *ke= y, *val;
=A0=A0=A0 ssize_t len;


=A0=A0=A0 key =3D "KEY1";
=A0=A0=A0 val =3D "VAL1= ";
=A0=A0=A0 len =3D strlen(key);
=A0=A0=A0 local_snprintf(buf, = sizeof buf, "%sKey %s (%ld) Value %s\n",
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "->",
=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 key,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 len,
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 val);

=A0=A0=A0 /* printf= (buf); */
}

No crash with Sun Studio 12 (no update) on Solaris 10 U5.
--001485ea0ff42e7dee0474bbf486--