You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Alexander L. Belikoff" <ab...@vallinor4.com> on 2004/06/20 06:13:17 UTC
'svnadmin load' crashing reliably in Fedora Core 1
Hello everyone,
I've been trying to build Subversion 1.0.0 and upwards in Fedora Core 1 and I
keep getting run-time crashes using every snapshot I try.
The test is the as follows:
rm -rf /tmp/repotest/ ; svnadmin create /tmp/repotest && \
echo repository created && svnadmin load /tmp/repotest < /dev/null
Svnadmin segfaults during the load operation in the following context:
=======================================================
[Thread debugging using libthread_db enabled]
[New Thread -1085164896 (LWP 8339)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1085164896 (LWP 8339)]
apr_palloc (pool=0x14841b, size=1344539) at apr_pools.c:608
608 if (size < (apr_size_t)(active->endp - active->first_avail)) {
(gdb) p active
$1 = (apr_memnode_t *) 0x6556000a
(gdb) p *active
Cannot access memory at address 0x6556000a
(gdb)
========================================================
The snapshot is built w/ apr and apr utils taken from Apache 2.0.49 and BDB
4.2.52.NC. The library depndencies look like this:
========================================================
libsvn_repos-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_repos-1.so.0
(0x005e0000)
libsvn_fs-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_fs-1.so.0
(0x0027f000)
libsvn_fs_fs-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_fs_fs-1.so.0
(0x00b92000)
libsvn_fs_base-1.so.0
=> /home/abel/nw/svn/inst/lib/libsvn_fs_base-1.so.0 (0x008db000)
libsvn_delta-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_delta-1.so.0
(0x0024b000)
libsvn_subr-1.so.0 => /home/abel/nw/svn/inst/lib/libsvn_subr-1.so.0
(0x00111000)
libaprutil-0.so.0 => /home/abel/nw/svn/inst/lib/libaprutil-0.so.0
(0x0057b000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x0012f000)
libdb-4.2.so => /home/abel/nw/svn/inst/lib/libdb-4.2.so (0x00136000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00ac8000)
libapr-0.so.0 => /home/abel/nw/svn/inst/lib/libapr-0.so.0 (0x00f4f000)
librt.so.1 => /lib/tls/librt.so.1 (0x001dc000)
libm.so.6 => /lib/tls/libm.so.6 (0x008ad000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x001f0000)
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 (0x00772000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0075a000)
========================================================
I would appreciate any hint on how to overcome the aforementioned problem.
Thanks in advance,
--
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
Re: 'svnadmin load' crashing reliably in Fedora Core 1
Posted by "Alexander L. Belikoff" <ab...@vallinor4.com>.
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)
Re: 'svnadmin load' crashing reliably in Fedora Core 1
Posted by Garrett Rooney <ro...@gmail.com>.
On Sun, 20 Jun 2004 02:13:17 -0400, Alexander L. Belikoff
<ab...@vallinor4.com> wrote:
>
> Hello everyone,
>
> I've been trying to build Subversion 1.0.0 and upwards in Fedora Core 1 and I
> keep getting run-time crashes using every snapshot I try.
>
> The test is the as follows:
>
> rm -rf /tmp/repotest/ ; svnadmin create /tmp/repotest && \
> echo repository created && svnadmin load /tmp/repotest < /dev/null
>
> Svnadmin segfaults during the load operation in the following context:
>
> =======================================================
> [Thread debugging using libthread_db enabled]
> [New Thread -1085164896 (LWP 8339)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1085164896 (LWP 8339)]
> apr_palloc (pool=0x14841b, size=1344539) at apr_pools.c:608
> 608 if (size < (apr_size_t)(active->endp - active->first_avail)) {
> (gdb) p active
> $1 = (apr_memnode_t *) 0x6556000a
> (gdb) p *active
> Cannot access memory at address 0x6556000a
> (gdb)
> ========================================================
First off, why are you trying to pass svnadmin load /dev/null?
Usually one would feed svnadmin load the contents of a dumpfile...
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?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svnadmin load' crashing reliably in Fedora Core 1
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Sun, 20 Jun 2004, Alexander L. Belikoff wrote:
> I've been trying to build Subversion 1.0.0 and upwards in Fedora Core 1 and I
> keep getting run-time crashes using every snapshot I try.
>
Sorry to hear you are having problems. Have you looked at my Fedora Core
1 RPMS? Unless you are just wanting to try your hand at compiling, give
my RPMs a try...no use having to re-invent the wheel. :-)
Note: Since I no longer have a Fedora 1 system someone else is now
building the RPMs for me to put on my server.
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org