You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2010/03/10 18:26:51 UTC
Crash in apr_psprintf(), 1.4.x branch
In trying to get Subversion acquainted with the 1.4.x branch, I
encountered the a crash within an invocation of apr_psprintf(). The
attached patch adds a test case demonstrating the crash. The patch is
against 1.4.x, but applies to trunk as well, where the bug is also
present.
The test case is essentially a replication of one of the calls to
apr_psprintf() that happens deep within Subversion, and which
functions just fine when working against 1.3.x. In digging a little
deeper, it appears that the var arg pointer isn't being advanced
properly at some point in apr_vformatter(), but I'm hoping that
someone more familiar with the code will be able to figure out what's
really going on.
Cheers,
-Hyrum
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'm removing the configure.in patch (added long-ago) which tried to
at least start allowing APR and OS X 10.6.x (and universal) to
work nicely...
On Apr 8, 2010, at 11:47 AM, Jeff Trawick wrote:
> On Tue, Mar 16, 2010 at 11:45 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>>
>> On Mar 16, 2010, at 9:00 AM, Jim Jagielski wrote:
>>
>>>
>>> On Mar 10, 2010, at 5:45 PM, Hyrum K. Wright wrote:
>>>
>>>>
>>>> On Mar 10, 2010, at 11:26 AM, Hyrum K. Wright wrote:
>>>>
>>>>> In trying to get Subversion acquainted with the 1.4.x branch, I
>>>>> encountered the a crash within an invocation of apr_psprintf(). The
>>>>> attached patch adds a test case demonstrating the crash. The patch is
>>>>> against 1.4.x, but applies to trunk as well, where the bug is also
>>>>> present.
>>>>>
>>>>> The test case is essentially a replication of one of the calls to
>>>>> apr_psprintf() that happens deep within Subversion, and which
>>>>> functions just fine when working against 1.3.x. In digging a little
>>>>> deeper, it appears that the var arg pointer isn't being advanced
>>>>> properly at some point in apr_vformatter(), but I'm hoping that
>>>>> someone more familiar with the code will be able to figure out what's
>>>>> really going on.
>>>>
>>>> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>>>>
>>>> I'm a little new here, but would consider something like this is probably a blocker for 1.4.x. This may already have been discussed, but I haven't seen it, at least in the past couple of months.
>>>>
>>>
>>> Are you forcing -arch i386 ?
>>>
>>> It may be you are hitting the problem with APR and universal binaries under
>>> OS X. With Snow Leopard, this no longer works correctly, and
>>> trying to compile both as i386 and x86-64 results in problems because
>>> the actual C header files are different depending on which version is
>>> built. A patch was put in awhile ago to fix this, but was vetoed.
>>
>> I'm using whatever './configure' spits out on Snow Leopard. I don't see an explicit '-arch' flag in the compiler flags
>
> On Snow Leopard you must set the arch manually. For example:
>
> CC="cc -arch i386" ./configure ...
>
> Are you encountering any problems on Snow Leopard if you set the arch
> (either to 32-bit or 64-bit)?
>
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, Mar 16, 2010 at 11:45 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Mar 16, 2010, at 9:00 AM, Jim Jagielski wrote:
>
>>
>> On Mar 10, 2010, at 5:45 PM, Hyrum K. Wright wrote:
>>
>>>
>>> On Mar 10, 2010, at 11:26 AM, Hyrum K. Wright wrote:
>>>
>>>> In trying to get Subversion acquainted with the 1.4.x branch, I
>>>> encountered the a crash within an invocation of apr_psprintf(). The
>>>> attached patch adds a test case demonstrating the crash. The patch is
>>>> against 1.4.x, but applies to trunk as well, where the bug is also
>>>> present.
>>>>
>>>> The test case is essentially a replication of one of the calls to
>>>> apr_psprintf() that happens deep within Subversion, and which
>>>> functions just fine when working against 1.3.x. In digging a little
>>>> deeper, it appears that the var arg pointer isn't being advanced
>>>> properly at some point in apr_vformatter(), but I'm hoping that
>>>> someone more familiar with the code will be able to figure out what's
>>>> really going on.
>>>
>>> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>>>
>>> I'm a little new here, but would consider something like this is probably a blocker for 1.4.x. This may already have been discussed, but I haven't seen it, at least in the past couple of months.
>>>
>>
>> Are you forcing -arch i386 ?
>>
>> It may be you are hitting the problem with APR and universal binaries under
>> OS X. With Snow Leopard, this no longer works correctly, and
>> trying to compile both as i386 and x86-64 results in problems because
>> the actual C header files are different depending on which version is
>> built. A patch was put in awhile ago to fix this, but was vetoed.
>
> I'm using whatever './configure' spits out on Snow Leopard. I don't see an explicit '-arch' flag in the compiler flags
On Snow Leopard you must set the arch manually. For example:
CC="cc -arch i386" ./configure ...
Are you encountering any problems on Snow Leopard if you set the arch
(either to 32-bit or 64-bit)?
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 16, 2010, at 9:00 AM, Jim Jagielski wrote:
>
> On Mar 10, 2010, at 5:45 PM, Hyrum K. Wright wrote:
>
>>
>> On Mar 10, 2010, at 11:26 AM, Hyrum K. Wright wrote:
>>
>>> In trying to get Subversion acquainted with the 1.4.x branch, I
>>> encountered the a crash within an invocation of apr_psprintf(). The
>>> attached patch adds a test case demonstrating the crash. The patch is
>>> against 1.4.x, but applies to trunk as well, where the bug is also
>>> present.
>>>
>>> The test case is essentially a replication of one of the calls to
>>> apr_psprintf() that happens deep within Subversion, and which
>>> functions just fine when working against 1.3.x. In digging a little
>>> deeper, it appears that the var arg pointer isn't being advanced
>>> properly at some point in apr_vformatter(), but I'm hoping that
>>> someone more familiar with the code will be able to figure out what's
>>> really going on.
>>
>> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>>
>> I'm a little new here, but would consider something like this is probably a blocker for 1.4.x. This may already have been discussed, but I haven't seen it, at least in the past couple of months.
>>
>
> Are you forcing -arch i386 ?
>
> It may be you are hitting the problem with APR and universal binaries under
> OS X. With Snow Leopard, this no longer works correctly, and
> trying to compile both as i386 and x86-64 results in problems because
> the actual C header files are different depending on which version is
> built. A patch was put in awhile ago to fix this, but was vetoed.
I'm using whatever './configure' spits out on Snow Leopard. I don't see an explicit '-arch' flag in the compiler flags
-Hyrum
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 10, 2010, at 5:45 PM, Hyrum K. Wright wrote:
>
> On Mar 10, 2010, at 11:26 AM, Hyrum K. Wright wrote:
>
>> In trying to get Subversion acquainted with the 1.4.x branch, I
>> encountered the a crash within an invocation of apr_psprintf(). The
>> attached patch adds a test case demonstrating the crash. The patch is
>> against 1.4.x, but applies to trunk as well, where the bug is also
>> present.
>>
>> The test case is essentially a replication of one of the calls to
>> apr_psprintf() that happens deep within Subversion, and which
>> functions just fine when working against 1.3.x. In digging a little
>> deeper, it appears that the var arg pointer isn't being advanced
>> properly at some point in apr_vformatter(), but I'm hoping that
>> someone more familiar with the code will be able to figure out what's
>> really going on.
>
> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>
> I'm a little new here, but would consider something like this is probably a blocker for 1.4.x. This may already have been discussed, but I haven't seen it, at least in the past couple of months.
>
Are you forcing -arch i386 ?
It may be you are hitting the problem with APR and universal binaries under
OS X. With Snow Leopard, this no longer works correctly, and
trying to compile both as i386 and x86-64 results in problems because
the actual C header files are different depending on which version is
built. A patch was put in awhile ago to fix this, but was vetoed.
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by Graham Leggett <mi...@sharp.fm>.
On 11 Mar 2010, at 7:08 PM, Hyrum K. Wright wrote:
>> I'm finding the results autoconf comes up with on Mac OS X 10.6
>> confusing. E.g.:
>>
>> #define SIZEOF_OFF_T 8
>>
>> and sizeof(APR_INT64_T) is 8 by definition
>>
>> but
>>
>> #define APR_INT64_T_FMT "ld"
>> #define APR_OFF_T_FMT "lld"
>>
>> so if INT64_T and OFF_T are the same size, why are they ending up
>> with
>> different format strings?
>
> That confused me, too. Doing some archaeological digging, it
> appears that Jim made that change in r809745. There's even a note
> in configure.in that on darwin 'long long' == 'long'. I do not know
> the rational.
This is part of an unfinished effort to support MacOSX universal
binaries, which on 10.6 gives you both 64 bit and 32 bit builds of the
same code in the same library (side by side).
As I recall jorton vetoed the effort, I need to dig out why.
Regards,
Graham
--
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 11, 2010, at 11:04 AM, Dan Poirier wrote:
> On Wed, 10 Mar 2010 17:50 -0600, "William A. Rowe Jr."
> <wr...@rowe-clan.net> wrote:
>> On 3/10/2010 4:45 PM, Hyrum K. Wright wrote:
>>>
>>> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>>
>> Yes, this function isn't maintained on Mac OS/X. Which is something
>> of a surprise, given the number of Mac fans around here!
>>
>> The defintions are very clear, %d must handle an (int) sized object,
>> %ld must handle a (long) sized object, and %lld must handle any
>> long long int sized object. Patches welcome.
>
> I'm finding the results autoconf comes up with on Mac OS X 10.6
> confusing. E.g.:
>
> #define SIZEOF_OFF_T 8
>
> and sizeof(APR_INT64_T) is 8 by definition
>
> but
>
> #define APR_INT64_T_FMT "ld"
> #define APR_OFF_T_FMT "lld"
>
> so if INT64_T and OFF_T are the same size, why are they ending up with
> different format strings?
That confused me, too. Doing some archaeological digging, it appears that Jim made that change in r809745. There's even a note in configure.in that on darwin 'long long' == 'long'. I do not know the rational.
-Hyrum
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by Dan Poirier <po...@pobox.com>.
On Wed, 10 Mar 2010 17:50 -0600, "William A. Rowe Jr."
<wr...@rowe-clan.net> wrote:
> On 3/10/2010 4:45 PM, Hyrum K. Wright wrote:
> >
> > Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>
> Yes, this function isn't maintained on Mac OS/X. Which is something
> of a surprise, given the number of Mac fans around here!
>
> The defintions are very clear, %d must handle an (int) sized object,
> %ld must handle a (long) sized object, and %lld must handle any
> long long int sized object. Patches welcome.
I'm finding the results autoconf comes up with on Mac OS X 10.6
confusing. E.g.:
#define SIZEOF_OFF_T 8
and sizeof(APR_INT64_T) is 8 by definition
but
#define APR_INT64_T_FMT "ld"
#define APR_OFF_T_FMT "lld"
so if INT64_T and OFF_T are the same size, why are they ending up with
different format strings?
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 10, 2010, at 5:50 PM, William A. Rowe Jr. wrote:
> On 3/10/2010 4:45 PM, Hyrum K. Wright wrote:
>>
>> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
>
> Yes, this function isn't maintained on Mac OS/X. Which is something
> of a surprise, given the number of Mac fans around here!
>
> The defintions are very clear, %d must handle an (int) sized object,
> %ld must handle a (long) sized object, and %lld must handle any
> long long int sized object. Patches welcome.
>
> I plan to patch win32 to accept %I64[ld] because long long type was added
> with VS 7.1, while %ll was not added until the more recent Visual Studio 8.
> I64d goes further back in time to 6.0 or prior, and is how we specified
> the format tag for APR_OFF_T_FMT etc.
Digging even further. It appears that the parser is attempting to match APR_INT64_T_FMT first, which may be of variable size. On OS X, this is defined as 'ld', but the parser mistakenly matches APR_OFF_T_FMT, which is defined as 'lld' for this case.
Attached is a patch which adds another block which preemptively matches APR_OFF_T_FMT. I've tested it on OS X and a 64-bit Linux system.
-Hyrum
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/10/2010 4:45 PM, Hyrum K. Wright wrote:
>
> Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
Yes, this function isn't maintained on Mac OS/X. Which is something
of a surprise, given the number of Mac fans around here!
The defintions are very clear, %d must handle an (int) sized object,
%ld must handle a (long) sized object, and %lld must handle any
long long int sized object. Patches welcome.
I plan to patch win32 to accept %I64[ld] because long long type was added
with VS 7.1, while %ll was not added until the more recent Visual Studio 8.
I64d goes further back in time to 6.0 or prior, and is how we specified
the format tag for APR_OFF_T_FMT etc.
Re: Crash in apr_psprintf(), 1.4.x branch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Mar 10, 2010, at 11:26 AM, Hyrum K. Wright wrote:
> In trying to get Subversion acquainted with the 1.4.x branch, I
> encountered the a crash within an invocation of apr_psprintf(). The
> attached patch adds a test case demonstrating the crash. The patch is
> against 1.4.x, but applies to trunk as well, where the bug is also
> present.
>
> The test case is essentially a replication of one of the calls to
> apr_psprintf() that happens deep within Subversion, and which
> functions just fine when working against 1.3.x. In digging a little
> deeper, it appears that the var arg pointer isn't being advanced
> properly at some point in apr_vformatter(), but I'm hoping that
> someone more familiar with the code will be able to figure out what's
> really going on.
Digging deeper, it appears to be an error in apr_vformatter() when parsing the format '%lld'. I'm running the tests on Mac OS X where APR_OFF_FMT_T is defined as lld, so this format occurs frequently. Consequently, I'm also seeing a failure in testfmt at line 63, where the parser is attempting to parse APR_OFF_FMT_T, but failing. Can anybody else replicate this bug?
I'm a little new here, but would consider something like this is probably a blocker for 1.4.x. This may already have been discussed, but I haven't seen it, at least in the past couple of months.
-Hyrum