On Sunday 20 June 2004 09:53 am, Garrett Rooney wrote:
> First off, why are you trying to pass svnadmin load /dev/null?
> Usually one would feed svnadmin load the contents of a dumpfile...
Yes, usually. :-) Unfortunately, I was getting svnadmin crashing on a file.
Any file. Using /dev/null is just the easiest way to reproduce it.
> Second, I can't reproduce this crash with a version of svnadmin built
> from the trunk, so it's possible that we've already fixed it. Could
> you send a backtrace from gdb so we can see what it's trying to do
> when it crashes?
Gladly (oh and BTW I was using the trunk as of yesterday)
========================================================
(gdb) r load /tmp/repotest < /dev/null
Starting program: /mnt/dsk2/home/abel/nw/svn/inst/bin/svnadmin
load /tmp/repotest < /dev/null
[Thread debugging using libthread_db enabled]
[New Thread -1084382560 (LWP 21161)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1084382560 (LWP 21161)]
apr_palloc (pool=0x1c941b, size=1872923) at apr_pools.c:608
608 if (size < (apr_size_t)(active->endp - active->first_avail)) {
(gdb) bt
#0 apr_palloc (pool=0x1c941b, size=1872923) at apr_pools.c:608
#1 0x001c754a in svn_stringbuf_ncreate ()
from /home/abel/nw/svn/inst/lib/libsvn_repos-1.so.0
#2 0x001c75a7 in svn_stringbuf_create ()
from /home/abel/nw/svn/inst/lib/libsvn_repos-1.so.0
#3 0x001c6e12 in svn_stream_readline ()
from /home/abel/nw/svn/inst/lib/libsvn_repos-1.so.0
#4 0x001a5f25 in svn_repos_parse_dumpstream2 (stream=0x91b20f8,
parse_fns=0x91b21a8, parse_baton=0x91b2190,
cancel_func=0x8049740 <check_cancel>, cancel_baton=0x0, pool=0x91b0920)
at subversion/libsvn_repos/load.c:478
#5 0x001a7029 in svn_repos_load_fs (repos=0x91b0e10, dumpstream=0x91b20f8,
feedback_stream=0x91b2158, uuid_action=svn_repos_load_uuid_default,
parent_dir=0x0, cancel_func=0x8049740 <check_cancel>, cancel_baton=0x0,
pool=0x91b0920) at subversion/libsvn_repos/load.c:1216
#6 0x08049f0c in subcommand_load (os=0x91b0958, baton=0xbff16230,
pool=0x91b0920) at subversion/svnadmin/main.c:568
#7 0x0804aa79 in main (argc=2, argv=0xbff16334)
at subversion/svnadmin/main.c:1141
(gdb) p *active
Cannot access memory at address 0x6556000a
(gdb)
========================================================
The dynamic link map looks like:
========================================================
$ ldd /home/abel/nw/svn/inst/bin/svnadmin
libsvn_repos-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_repos-1.so.0
(0x00cc5000)
libsvn_fs-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_fs-1.so.0
(0x00d1a000)
libsvn_fs_fs-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_fs_fs-1.so.0
(0x00636000)
libsvn_fs_base-1.so.0
=> /home/abel/nw/svn/inst/lib/libsvn_fs_base-1.so.0 (0x0044f000)
libsvn_delta-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_delta-1.so.0
(0x00111000)
libsvn_subr-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_subr-1.so.0
(0x0039b000)
libaprutil-0.so.0 => /home/abel/nw/svn/inst/lib/libaprutil-0.so.0
(0x00792000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x008d6000)
libdb-4.2.so => /home/abel/nw/svn/inst/lib/libdb-4.2.so (0x004a4000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00ac8000)
libapr-0.so.0 => /home/abel/nw/svn/inst/lib/libapr-0.so.0 (0x0015a000)
librt.so.1 => /lib/tls/librt.so.1 (0x00126000)
libm.so.6 => /lib/tls/libm.so.6 (0x008ad000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00178000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00d45000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x009d9000)
libdl.so.2 => /lib/libdl.so.2 (0x008d1000)
libc.so.6 => /lib/tls/libc.so.6 (0x001a5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0075a000)
========================================================
Here's the ltrace, just in case:
========================================================
$ ltrace /home/abel/nw/svn/inst/bin/svnadmin load /tmp/repotest < /dev/null
__libc_start_main(0x0804a528, 3, 0xbff59e34, 0x0804abd0, 0x0804ac18
<unfinished ...>
svn_cmdline_init(0x0804aeb2, 0x0036c7a0, 0xbff59c60, 0, 0x0a368a32) = 0
apr_allocator_create(0xbff59c5c, 0x0036c7a0, 0xbff59c60, 0, 0x0a368a32) = 0
apr_allocator_max_free_set(0x09e19898, 0x00400000, 0xbff59c60, 0, 0x0a368a32)
= 1024
svn_pool_create_ex(0, 0x09e19898, 0xbff59c60, 0, 0x0a368a32) = 0x09e19920
apr_allocator_owner_set(0x09e19898, 0x09e19920, 0xbff59c60, 0, 0x09e19920) =
0x09e19898
memset(0xbff59d30, '\000', 84) = 0xbff59d30
apr_getopt_init(0xbff59c58, 0x09e19920, 3, 0xbff59e34, 0x09e19920) = 0
apr_getopt_long(0x09e19958, 0x0804c0a0, 0xbff59c50, 0xbff59c54, 0x09e19920) =
70014
svn_opt_get_canonical_subcommand(0x0804c1c0, 0xbff8c835, 0xbff59c50,
0xbff59c54, 0x09e19920) = 0x0804c7e0
svn_utf_cstring_to_utf8(0xbff59d30, 0xbff8c83a, 0x09e19920, 2, 49) = 0
svn_path_internal_style(0x09e19b90, 0x09e19920, 0x09e19920, 2, 49
<unfinished ...>
svn_path_canonicalize(0x09e19b90, 0x09e19920, 0x09e19920, 2, 49) = 0x09e19b90
svn_path_is_url(0x09e19b90, 0x09e19920, 0x09e19920, 2, 49) = 0
apr_signal(2, 0x08049724, 0x09e19920, 0x08049e84, 0x09e19920) = 0
apr_signal(1, 0x08049724, 0x09e19920, 0x08049e84, 0x09e19920) = 0
apr_signal(15, 0x08049724, 0x09e19920, 0x08049e84, 0x09e19920) = 0
apr_signal(13, 1, 0x09e19920, 0x08049e84, 0x09e19920) = 0
svn_repos_open(0xbff59c1c, 0x09e19b90, 0x09e19920, 0, 0 <unfinished ...>
svn_pool_create_ex(0x09e19920, 0, 0x09e19920, 0x09e19e40, 0xbff59b78) =
0x09e1b928
<... svn_repos_open resumed> ) = 0
svn_repos_fs(0x09e19e10, 0x080498dc, 0, 0x09e21280, 0) = 0x09e1b960
svn_fs_set_warning_func(0x09e1b960, 0x080498dc, 0, 0x09e21280, 0) = 0x09e1b960
apr_file_open_stdin(0xbff59bec, 0x09e19920, 0xbff59bf8, 0x08049935,
0x09e1b960) = 0
svn_stream_from_aprfile(0x09e1b0a8, 0x09e19920, 0xbff59bf8, 0x08049935,
0x09e1b960) = 0x09e1b0f8
apr_file_open_stdout(0xbff59bec, 0x09e19920, 0xbff59bf8, 0x08049935,
0x09e1b960) = 0
svn_stream_from_aprfile(0x09e1b108, 0x09e19920, 0xbff59bf8, 0x08049935,
0x09e1b960) = 0x09e1b158
svn_repos_load_fs(0x09e19e10, 0x09e1b0f8, 0x09e1b158, 0, 0 <unfinished ...>
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
========================================================
One thing that is weird about this trace is the fact that although libapr is
dynamically linked to svnadmin (see ldd output above), ltrace doesn't show
any calls to it, implying the static linkage. I'll double-check the linke
command used to link svnadmin...
Finally, I've attached the empty repository I've created for the test. I'm
positive that it is ok, but it's better to have all pieces handy
--
Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P. 424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 20 16:55:58 2004