You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Rainer Jung <ra...@kippdata.de> on 2015/08/06 16:36:48 UTC
1.9.0 crash in ra_test (Solaris, Bus error, Alignment)
I get a bus error during running the subversion 1.9.0 test suite on
Solaris Sparc. The crash happens in ra_test. The root cause seems to be
an alinment problem. Sparc is picky about 8 Bytes alignment for 64Bit
data types.
Stack:
#0 0xff29f194 in vparse_tuple (pool=pool@entry=0x35f10,
fmt=fmt@entry=0xffbff264, ap=ap@entry=0xffbff20c,
items=<error reading variable: Unhandled dwarf expression opcode
0xfa>, items=<error reading variable: Unhandled dwarf expression opcode
0xfa>)
at subversion/libsvn_ra_svn/marshal.c:1310
#1 0xff2a0a14 in svn_ra_svn__read_cmd_response
(conn=conn@entry=0x69000, pool=pool@entry=0x35f10, fmt=0xff2a9af0
"nnll") at subversion/libsvn_ra_svn/marshal.c:1540
#2 0xff29925c in open_session (sess_p=sess_p@entry=0xffbff338,
url=url@entry=0x31f40 "svn+test://localhost/test-repo-tunnel",
uri=uri@entry=0xffbff33c,
tunnel_name=tunnel_name@entry=0x56100 "test",
tunnel_argv=tunnel_argv@entry=0x0, config=config@entry=0x0,
callbacks=callbacks@entry=0x31f68,
callbacks_baton=callbacks_baton@entry=0x0,
auth_baton=auth_baton@entry=0x56018, result_pool=result_pool@entry=0x35f10,
scratch_pool=<error reading variable: Unhandled dwarf expression
opcode 0xfa>) at subversion/libsvn_ra_svn/client.c:717
#3 0xff299b38 in ra_svn_open (session=0x560e8, corrected_url=<optimized
out>, url=0x31f40 "svn+test://localhost/test-repo-tunnel",
callbacks=0x31f68, callback_baton=0x0,
auth_baton=0x56018, config=0x0, result_pool=0x55f90,
scratch_pool=0x53f88) at subversion/libsvn_ra_svn/client.c:854
#4 0xff2c7938 in svn_ra_open4 (session_p=session_p@entry=0xffbff490,
corrected_url_p=corrected_url_p@entry=0x0,
repos_URL=repos_URL@entry=0x31f40
"svn+test://localhost/test-repo-tunnel", uuid=uuid@entry=0x0,
callbacks=0x31f68, callback_baton=callback_baton@entry=0x0,
config=config@entry=0x0, pool=pool@entry=0x49f60) at
subversion/libsvn_ra/ra_loader.c:384
#5 0x00012578 in tunnel_callback_test (opts=<optimized out>,
pool=0x31f00) at subversion/tests/libsvn_ra/ra-test.c:392
#6 0xff37557c in do_test_num (progname=0x2e513 "ra-test",
test_num=test_num@entry=3, test_funcs=test_funcs@entry=0x24778,
msg_only=msg_only@entry=0,
opts=opts@entry=0xffbff5cc, header_msg=header_msg@entry=0x0,
pool=pool@entry=0x31f00) at subversion/tests/svn_test_main.c:466
#7 0xff376580 in svn_test_main (argc=4, argv=<optimized out>,
max_threads=<optimized out>, test_funcs=0x24778) at
subversion/tests/svn_test_main.c:1048
#8 0x00011378 in _start ()
Position of crash:
#0 0xff29f194 in vparse_tuple (pool=pool@entry=0x35f10,
fmt=fmt@entry=0xffbff264, ap=ap@entry=0xffbff20c,
items=<error reading variable: Unhandled dwarf expression opcode
0xfa>, items=<error reading variable: Unhandled dwarf expression opcode
0xfa>)
at subversion/libsvn_ra_svn/marshal.c:1310
1310 *va_arg(*ap, apr_uint64_t *) = elt->u.number;
elt is:
(gdb) print *elt
$2 = {kind = SVN_RA_SVN_NUMBER, u = {number = 2, string = 0x0, word =
0x0, list = 0x0}}
The addresses are:
elt address is: 0x7012c
elt->u and elt->u.number addresses are both: 0x70134
and the crash happens when elt->u.number is being accessed as an
apr_uint64_t under this address which is only 4 byte aligned.
I haven't tracked down, where elt is actually being allocated. That
would be the place to make sure, it is 8 byte aligned. It should be
automatic if allocated using its type svn_ra_svn_item_t, but maybe it is
allocated in a more generic way with a type the compiler can not align
correctly for the later use as svn_ra_svn_item_t.
I have not encountered this crash for 1.7 or 1.8. For 1.9 it happens
during every test run.
Regards,
Rainer
Re: 1.9.0 crash in ra_test (Solaris, Bus error, Alignment)
Posted by Rainer Jung <ra...@kippdata.de>.
Am 06.08.2015 um 17:54 schrieb Rainer Jung:
> Am 06.08.2015 um 16:36 schrieb Rainer Jung:
>> Position of crash:
>>
>> #0 0xff29f194 in vparse_tuple (pool=pool@entry=0x35f10,
>> fmt=fmt@entry=0xffbff264, ap=ap@entry=0xffbff20c,
>> items=<error reading variable: Unhandled dwarf expression opcode
>> 0xfa>, items=<error reading variable: Unhandled dwarf expression opcode
>> 0xfa>)
>> at subversion/libsvn_ra_svn/marshal.c:1310
>> 1310 *va_arg(*ap, apr_uint64_t *) = elt->u.number;
>>
>> elt is:
>>
>> (gdb) print *elt
>> $2 = {kind = SVN_RA_SVN_NUMBER, u = {number = 2, string = 0x0, word =
>> 0x0, list = 0x0}}
>>
>> The addresses are:
>>
>> elt address is: 0x7012c
>> elt->u and elt->u.number addresses are both: 0x70134
>>
>> and the crash happens when elt->u.number is being accessed as an
>> apr_uint64_t under this address which is only 4 byte aligned.
>>
>> I haven't tracked down, where elt is actually being allocated. That
>> would be the place to make sure, it is 8 byte aligned. It should be
>> automatic if allocated using its type svn_ra_svn_item_t, but maybe it is
>> allocated in a more generic way with a type the compiler can not align
>> correctly for the later use as svn_ra_svn_item_t.
>
> I think the root cause is here (file subversion/libsvn_ra_svn/marshal.c):
>
> 1082 /* Allocate an APR array with room for (initially) 4 items.
> 1083 * We do this manually because lists are the most
> frequent protocol
> 1084 * element, often used to frame a single, optional value.
> We save
> 1085 * about 20% of total protocol handling time. */
> 1086 char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> 1087 + 4 *
> sizeof(svn_ra_svn_item_t));
> 1088 svn_ra_svn_item_t *data
> 1089 = (svn_ra_svn_item_t *)(buffer +
> sizeof(apr_array_header_t));
> 1090
> 1091 item->kind = SVN_RA_SVN_LIST;
> 1092 item->u.list = (apr_array_header_t *)buffer;
>
> "buffer" is not specifically aligned, the array members in "item->u.list
> = (apr_array_header_t *)buffer" could be misaligned.
>
> The following (ugly) workaround fixes it for me:
>
> --- subversion/libsvn_ra_svn/marshal.c.kpdt_orig Fri Feb 13
> 12:17:40 2015
> +++ subversion/libsvn_ra_svn/marshal.c Thu Aug 6 17:46:58 2015
> @@ -1083,10 +1083,16 @@
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
> - char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> +
> + /* Make sure the data part of the buffer has appropriate alignment
> + by prefixing it with a size that fits the needed
> apr_array_header_t
> + but is itself highly aligned. */
> + size_t offset = sizeof(apr_array_header_t) / 8 * 8;
Oups, this is wrong, it should have been (...+7)/8*8. But instead simply use
size_t offset = APR_ALIGN(sizeof(apr_array_header_t), 8);
> +
> + char *buffer = apr_palloc(pool, offset
> + 4 * sizeof(svn_ra_svn_item_t));
> svn_ra_svn_item_t *data
> - = (svn_ra_svn_item_t *)(buffer + sizeof(apr_array_header_t));
> + = (svn_ra_svn_item_t *)(buffer + offset);
>
> item->kind = SVN_RA_SVN_LIST;
> item->u.list = (apr_array_header_t *)buffer;
>
> But of course its a bit rough, because it would apply on all platforms,
> even if not needed. Also on some (future?) platforms, the alignment for
> 8 bytes might not always be correct.
>
> It's a bit tragic that this code part is prefixed with:
>
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
>
> and the trap is that doing it manually often is harder than expected.
> Switching to apr_array_make() would have not introduced this bug, but of
> course you did it for a reason.
>
> Let me know, if I should test any other patch.
>
> Regards,
>
> Rainer
Re: 1.9.0 crash in ra_test (Solaris, Bus error, Alignment)
Posted by Rainer Jung <ra...@kippdata.de>.
Am 06.08.2015 um 17:54 schrieb Rainer Jung:
> I think the root cause is here (file subversion/libsvn_ra_svn/marshal.c):
>
> 1082 /* Allocate an APR array with room for (initially) 4 items.
> 1083 * We do this manually because lists are the most
> frequent protocol
> 1084 * element, often used to frame a single, optional value.
> We save
> 1085 * about 20% of total protocol handling time. */
> 1086 char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> 1087 + 4 *
> sizeof(svn_ra_svn_item_t));
> 1088 svn_ra_svn_item_t *data
> 1089 = (svn_ra_svn_item_t *)(buffer +
> sizeof(apr_array_header_t));
> 1090
> 1091 item->kind = SVN_RA_SVN_LIST;
> 1092 item->u.list = (apr_array_header_t *)buffer;
>
> "buffer" is not specifically aligned, the array members in "item->u.list
> = (apr_array_header_t *)buffer" could be misaligned.
>
> The following (ugly) workaround fixes it for me:
>
> --- subversion/libsvn_ra_svn/marshal.c.kpdt_orig Fri Feb 13
> 12:17:40 2015
> +++ subversion/libsvn_ra_svn/marshal.c Thu Aug 6 17:46:58 2015
> @@ -1083,10 +1083,16 @@
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
> - char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> +
> + /* Make sure the data part of the buffer has appropriate alignment
> + by prefixing it with a size that fits the needed
> apr_array_header_t
> + but is itself highly aligned. */
> + size_t offset = sizeof(apr_array_header_t) / 8 * 8;
> +
> + char *buffer = apr_palloc(pool, offset
> + 4 * sizeof(svn_ra_svn_item_t));
> svn_ra_svn_item_t *data
> - = (svn_ra_svn_item_t *)(buffer + sizeof(apr_array_header_t));
> + = (svn_ra_svn_item_t *)(buffer + offset);
>
> item->kind = SVN_RA_SVN_LIST;
> item->u.list = (apr_array_header_t *)buffer;
>
> But of course its a bit rough, because it would apply on all platforms,
> even if not needed. Also on some (future?) platforms, the alignment for
> 8 bytes might not always be correct.
>
> It's a bit tragic that this code part is prefixed with:
>
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
>
> and the trap is that doing it manually often is harder than expected.
> Switching to apr_array_make() would have not introduced this bug, but of
> course you did it for a reason.
The switch was introduced in r1485851. It is not part of 1.7 or 1.8.
Regards,
Rainer
Re: 1.9.0 crash in ra_test (Solaris, Bus error, Alignment)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 6 August 2015 at 18:54, Rainer Jung <ra...@kippdata.de> wrote:
> Am 06.08.2015 um 16:36 schrieb Rainer Jung:
>>
>> Position of crash:
>>
>> #0 0xff29f194 in vparse_tuple (pool=pool@entry=0x35f10,
>> fmt=fmt@entry=0xffbff264, ap=ap@entry=0xffbff20c,
>> items=<error reading variable: Unhandled dwarf expression opcode
>> 0xfa>, items=<error reading variable: Unhandled dwarf expression opcode
>> 0xfa>)
>> at subversion/libsvn_ra_svn/marshal.c:1310
>> 1310 *va_arg(*ap, apr_uint64_t *) = elt->u.number;
>>
>> elt is:
>>
>> (gdb) print *elt
>> $2 = {kind = SVN_RA_SVN_NUMBER, u = {number = 2, string = 0x0, word =
>> 0x0, list = 0x0}}
>>
>> The addresses are:
>>
>> elt address is: 0x7012c
>> elt->u and elt->u.number addresses are both: 0x70134
>>
>> and the crash happens when elt->u.number is being accessed as an
>> apr_uint64_t under this address which is only 4 byte aligned.
>>
>> I haven't tracked down, where elt is actually being allocated. That
>> would be the place to make sure, it is 8 byte aligned. It should be
>> automatic if allocated using its type svn_ra_svn_item_t, but maybe it is
>> allocated in a more generic way with a type the compiler can not align
>> correctly for the later use as svn_ra_svn_item_t.
>
>
> I think the root cause is here (file subversion/libsvn_ra_svn/marshal.c):
>
> 1082 /* Allocate an APR array with room for (initially) 4 items.
> 1083 * We do this manually because lists are the most frequent
> protocol
> 1084 * element, often used to frame a single, optional value. We
> save
> 1085 * about 20% of total protocol handling time. */
> 1086 char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> 1087 + 4 *
> sizeof(svn_ra_svn_item_t));
> 1088 svn_ra_svn_item_t *data
> 1089 = (svn_ra_svn_item_t *)(buffer +
> sizeof(apr_array_header_t));
> 1090
> 1091 item->kind = SVN_RA_SVN_LIST;
> 1092 item->u.list = (apr_array_header_t *)buffer;
>
> "buffer" is not specifically aligned, the array members in "item->u.list =
> (apr_array_header_t *)buffer" could be misaligned.
>
> The following (ugly) workaround fixes it for me:
>
> --- subversion/libsvn_ra_svn/marshal.c.kpdt_orig Fri Feb 13 12:17:40
> 2015
> +++ subversion/libsvn_ra_svn/marshal.c Thu Aug 6 17:46:58 2015
> @@ -1083,10 +1083,16 @@
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
> - char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> +
> + /* Make sure the data part of the buffer has appropriate alignment
> + by prefixing it with a size that fits the needed
> apr_array_header_t
> + but is itself highly aligned. */
> + size_t offset = sizeof(apr_array_header_t) / 8 * 8;
> +
> + char *buffer = apr_palloc(pool, offset
> + 4 * sizeof(svn_ra_svn_item_t));
> svn_ra_svn_item_t *data
> - = (svn_ra_svn_item_t *)(buffer + sizeof(apr_array_header_t));
> + = (svn_ra_svn_item_t *)(buffer + offset);
>
> item->kind = SVN_RA_SVN_LIST;
> item->u.list = (apr_array_header_t *)buffer;
>
> But of course its a bit rough, because it would apply on all platforms, even
> if not needed. Also on some (future?) platforms, the alignment for 8 bytes
> might not always be correct.
>
> It's a bit tragic that this code part is prefixed with:
>
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
>
> and the trap is that doing it manually often is harder than expected.
> Switching to apr_array_make() would have not introduced this bug, but of
> course you did it for a reason.
>
I really doubt that saving one apr_palloc() call even for such hot
space could give 20% improvements: apr_palloc() is pretty optimized.
May be all changes in r1485851 commit gives 20% protocol handling time
improvement, but not this particural change.
--
Ivan Zhakov
Re: 1.9.0 crash in ra_test (Solaris, Bus error, Alignment)
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Aug 6, 2015 at 4:54 PM, Rainer Jung <ra...@kippdata.de> wrote:
> Am 06.08.2015 um 16:36 schrieb Rainer Jung:
>
>> Position of crash:
>>
>> #0 0xff29f194 in vparse_tuple (pool=pool@entry=0x35f10,
>> fmt=fmt@entry=0xffbff264, ap=ap@entry=0xffbff20c,
>> items=<error reading variable: Unhandled dwarf expression opcode
>> 0xfa>, items=<error reading variable: Unhandled dwarf expression opcode
>> 0xfa>)
>> at subversion/libsvn_ra_svn/marshal.c:1310
>> 1310 *va_arg(*ap, apr_uint64_t *) = elt->u.number;
>>
>> elt is:
>>
>> (gdb) print *elt
>> $2 = {kind = SVN_RA_SVN_NUMBER, u = {number = 2, string = 0x0, word =
>> 0x0, list = 0x0}}
>>
>> The addresses are:
>>
>> elt address is: 0x7012c
>> elt->u and elt->u.number addresses are both: 0x70134
>>
>> and the crash happens when elt->u.number is being accessed as an
>> apr_uint64_t under this address which is only 4 byte aligned.
>>
>> I haven't tracked down, where elt is actually being allocated. That
>> would be the place to make sure, it is 8 byte aligned. It should be
>> automatic if allocated using its type svn_ra_svn_item_t, but maybe it is
>> allocated in a more generic way with a type the compiler can not align
>> correctly for the later use as svn_ra_svn_item_t.
>>
>
> I think the root cause is here (file subversion/libsvn_ra_svn/marshal.c):
>
> 1082 /* Allocate an APR array with room for (initially) 4 items.
> 1083 * We do this manually because lists are the most frequent
> protocol
> 1084 * element, often used to frame a single, optional value.
> We save
> 1085 * about 20% of total protocol handling time. */
> 1086 char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> 1087 + 4 *
> sizeof(svn_ra_svn_item_t));
> 1088 svn_ra_svn_item_t *data
> 1089 = (svn_ra_svn_item_t *)(buffer +
> sizeof(apr_array_header_t));
> 1090
> 1091 item->kind = SVN_RA_SVN_LIST;
> 1092 item->u.list = (apr_array_header_t *)buffer;
>
> "buffer" is not specifically aligned, the array members in "item->u.list =
> (apr_array_header_t *)buffer" could be misaligned.
>
> The following (ugly) workaround fixes it for me:
>
> --- subversion/libsvn_ra_svn/marshal.c.kpdt_orig Fri Feb 13
> 12:17:40 2015
> +++ subversion/libsvn_ra_svn/marshal.c Thu Aug 6 17:46:58 2015
> @@ -1083,10 +1083,16 @@
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
> - char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
> +
> + /* Make sure the data part of the buffer has appropriate alignment
> + by prefixing it with a size that fits the needed
> apr_array_header_t
> + but is itself highly aligned. */
> + size_t offset = sizeof(apr_array_header_t) / 8 * 8;
> +
> + char *buffer = apr_palloc(pool, offset
> + 4 * sizeof(svn_ra_svn_item_t));
> svn_ra_svn_item_t *data
> - = (svn_ra_svn_item_t *)(buffer + sizeof(apr_array_header_t));
> + = (svn_ra_svn_item_t *)(buffer + offset);
>
> item->kind = SVN_RA_SVN_LIST;
> item->u.list = (apr_array_header_t *)buffer;
>
> But of course its a bit rough, because it would apply on all platforms,
> even if not needed. Also on some (future?) platforms, the alignment for 8
> bytes might not always be correct.
>
> It's a bit tragic that this code part is prefixed with:
>
> * We do this manually because lists are the most frequent protocol
> * element, often used to frame a single, optional value. We save
> * about 20% of total protocol handling time. */
>
> and the trap is that doing it manually often is harder than expected.
> Switching to apr_array_make() would have not introduced this bug, but of
> course you did it for a reason.
>
> Let me know, if I should test any other patch.
>
Hi Rainer,
Thanks for the report - it took me a while to figure out what the problem
is.
Apparently, the machine uses 32 bit pointers but reads 64 bit ints as atomic
values (i.e. using a native 64 bit read op) and requires that to be properly
aligned. I'll have to go through the code to check if there are other places
that imply "void * alignment is good enough".
The fix is in r1694533 and is scheduled for backport into 1.9.x.
-- Stefan^2.
Re: 1.9.0 crash in ra_test (Solaris, Bus error, Alignment)
Posted by Rainer Jung <ra...@kippdata.de>.
Am 06.08.2015 um 16:36 schrieb Rainer Jung:
> Position of crash:
>
> #0 0xff29f194 in vparse_tuple (pool=pool@entry=0x35f10,
> fmt=fmt@entry=0xffbff264, ap=ap@entry=0xffbff20c,
> items=<error reading variable: Unhandled dwarf expression opcode
> 0xfa>, items=<error reading variable: Unhandled dwarf expression opcode
> 0xfa>)
> at subversion/libsvn_ra_svn/marshal.c:1310
> 1310 *va_arg(*ap, apr_uint64_t *) = elt->u.number;
>
> elt is:
>
> (gdb) print *elt
> $2 = {kind = SVN_RA_SVN_NUMBER, u = {number = 2, string = 0x0, word =
> 0x0, list = 0x0}}
>
> The addresses are:
>
> elt address is: 0x7012c
> elt->u and elt->u.number addresses are both: 0x70134
>
> and the crash happens when elt->u.number is being accessed as an
> apr_uint64_t under this address which is only 4 byte aligned.
>
> I haven't tracked down, where elt is actually being allocated. That
> would be the place to make sure, it is 8 byte aligned. It should be
> automatic if allocated using its type svn_ra_svn_item_t, but maybe it is
> allocated in a more generic way with a type the compiler can not align
> correctly for the later use as svn_ra_svn_item_t.
I think the root cause is here (file subversion/libsvn_ra_svn/marshal.c):
1082 /* Allocate an APR array with room for (initially) 4 items.
1083 * We do this manually because lists are the most
frequent protocol
1084 * element, often used to frame a single, optional value.
We save
1085 * about 20% of total protocol handling time. */
1086 char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
1087 + 4 *
sizeof(svn_ra_svn_item_t));
1088 svn_ra_svn_item_t *data
1089 = (svn_ra_svn_item_t *)(buffer +
sizeof(apr_array_header_t));
1090
1091 item->kind = SVN_RA_SVN_LIST;
1092 item->u.list = (apr_array_header_t *)buffer;
"buffer" is not specifically aligned, the array members in "item->u.list
= (apr_array_header_t *)buffer" could be misaligned.
The following (ugly) workaround fixes it for me:
--- subversion/libsvn_ra_svn/marshal.c.kpdt_orig Fri Feb 13
12:17:40 2015
+++ subversion/libsvn_ra_svn/marshal.c Thu Aug 6 17:46:58 2015
@@ -1083,10 +1083,16 @@
* We do this manually because lists are the most frequent protocol
* element, often used to frame a single, optional value. We save
* about 20% of total protocol handling time. */
- char *buffer = apr_palloc(pool, sizeof(apr_array_header_t)
+
+ /* Make sure the data part of the buffer has appropriate alignment
+ by prefixing it with a size that fits the needed
apr_array_header_t
+ but is itself highly aligned. */
+ size_t offset = sizeof(apr_array_header_t) / 8 * 8;
+
+ char *buffer = apr_palloc(pool, offset
+ 4 * sizeof(svn_ra_svn_item_t));
svn_ra_svn_item_t *data
- = (svn_ra_svn_item_t *)(buffer + sizeof(apr_array_header_t));
+ = (svn_ra_svn_item_t *)(buffer + offset);
item->kind = SVN_RA_SVN_LIST;
item->u.list = (apr_array_header_t *)buffer;
But of course its a bit rough, because it would apply on all platforms,
even if not needed. Also on some (future?) platforms, the alignment for
8 bytes might not always be correct.
It's a bit tragic that this code part is prefixed with:
* We do this manually because lists are the most frequent protocol
* element, often used to frame a single, optional value. We save
* about 20% of total protocol handling time. */
and the trap is that doing it manually often is harder than expected.
Switching to apr_array_make() would have not introduced this bug, but of
course you did it for a reason.
Let me know, if I should test any other patch.
Regards,
Rainer