[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

1.9.0 crash in ra_test (Solaris, Bus error, Alignment)

From: Rainer Jung <rainer.jung_at_kippdata.de>
Date: Thu, 6 Aug 2015 16:36:48 +0200

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_at_entry=0x35f10,
fmt=fmt_at_entry=0xffbff264, ap=ap_at_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_at_entry=0x69000, pool=pool_at_entry=0x35f10, fmt=0xff2a9af0
"nnll") at subversion/libsvn_ra_svn/marshal.c:1540
#2 0xff29925c in open_session (sess_p=sess_p_at_entry=0xffbff338,
url=url_at_entry=0x31f40 "svn+test://localhost/test-repo-tunnel",
uri=uri_at_entry=0xffbff33c,
     tunnel_name=tunnel_name_at_entry=0x56100 "test",
tunnel_argv=tunnel_argv_at_entry=0x0, config=config_at_entry=0x0,
callbacks=callbacks_at_entry=0x31f68,
     callbacks_baton=callbacks_baton_at_entry=0x0,
auth_baton=auth_baton_at_entry=0x56018, result_pool=result_pool_at_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_at_entry=0xffbff490,
corrected_url_p=corrected_url_p_at_entry=0x0,
     repos_URL=repos_URL_at_entry=0x31f40
"svn+test://localhost/test-repo-tunnel", uuid=uuid_at_entry=0x0,
callbacks=0x31f68, callback_baton=callback_baton_at_entry=0x0,
     config=config_at_entry=0x0, pool=pool_at_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_at_entry=3, test_funcs=test_funcs_at_entry=0x24778,
msg_only=msg_only_at_entry=0,
     opts=opts_at_entry=0xffbff5cc, header_msg=header_msg_at_entry=0x0,
pool=pool_at_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_at_entry=0x35f10,
fmt=fmt_at_entry=0xffbff264, ap=ap_at_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
Received on 2015-08-06 16:37:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.