You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Evert van Grootheest <j....@euronext.nl> on 2003/09/11 10:14:39 UTC
large revision causes problems
Hello,
I am having these problems with SubVersion due to a really large
revision (or two) that's in the repo.
Here's the history:
There's a tree of files that I once tried to commit. It started to
transfer the data (printing all those dots), but after a long time it
reported an error. I think the server committed everything just fine,
because the tree is there when I browse through it with a web browser.
However, the client reported an error. Unfortunately, the exact error
got lost. The WC directory tree for the commit totals some 230Mb.
The working copy that the committed tree is in, still thinks that the
add was not committed.
If I try 'svn status', it reports in 18832 lines things that need to be
added.
If I try 'svn status -u' I can see from apache that it does a lot of
things for a while and then one worker shoots up to 99.x% CPU and stays
there for a long time. At some point in time, the client reports a timeout:
[issysd25@a05008 current]$ svn st -u
svn: RA layer request failed
svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
response body (http://a05009:65030)
All the while, the server is still very busy. These are the relevant
lines from the apache access log:
a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
/svn/MAL/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1" 207 758
a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
/svn/MAL/!svn/vcc/default HTTP/1.1" 207 397
a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
/svn/MAL/!svn/bln/16 HTTP/1.1" 207 450
a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
/svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1"
207 769
a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
/svn/MAL/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1" 207 758
a05008.aex.nl - - [10/Sep/2003:16:53:32 +0200] "PROPFIND
/svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers
HTTP/1.1" 207 2802
a05008.aex.nl - - [10/Sep/2003:16:53:32 +0200] "PROPFIND
/svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers/html
HTTP/1.1" 207 11436
a05008.aex.nl - - [10/Sep/2003:16:53:33 +0200] "PROPFIND
/svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers/html/tao
HTTP/1.1" 207 6158346
a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "REPORT
/svn/MAL/!svn/vcc/default HTTP/1.1" 200 9027147
Although I cannot guarantee that all these lines are the result of that
svn status call, the paths in them all relate it. And the number 16 (if
it is a revision number) matches that really big commit that failed
client-side that I mentioned above. As you can see, it returns some 15Mb
in total in the last two lines.
Any comments up till now are welcome.
As for questions....
What can I do to make this 'svn status -u' complete (apart from a faster
server, of course)?
Will all 'svn status -u' calls in the future have this problem?
What can I do to get this working better? How can I help you to improve
subversion with regard to this problem? I will not be able to do
extensive debugging, although investing a limited amount of time is no
problem.
I really would like to improve subversion and not expose the rest of the
company to this, as there are already some that are not convinced of the
advantages of svn over source safe (from a project point of view, not
necessarily technical).
Since, until now, there is no proprietary code in the repo yet, I could
mail/make available the database or a dump of it for testing. The db is
some 374Mb, while the zipped dump is still close to 60Mb.
Processing the dump somewhat reports these numbers:
[switch@a05009 dump]$ wc -l MAL.20030911
7258432 MAL.20030911
[switch@a05009 dump]$ grep -na Revision-number MAL.20030911
5:Revision-number: 0
15:Revision-number: 1
285:Revision-number: 2
1939:Revision-number: 3
1966:Revision-number: 4
2585:Revision-number: 5
3204:Revision-number: 6
3806:Revision-number: 7
4407:Revision-number: 8
5042:Revision-number: 9
4743620:Revision-number: 10
4743645:Revision-number: 11
4743670:Revision-number: 12
4743702:Revision-number: 13
4743724:Revision-number: 14
4746521:Revision-number: 15
4746558:Revision-number: 16
Thanks,
Jan Evert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Jan Evert van Grootheest <j....@euronext.nl>.
Hmm, of course I should've reported as well that the server is Apache
2.0.47 on RH 7.3/Advanced Server and SVN is 0.29 (all downloaded from
subversion.tigris.org).
The client is also 0.29.
-- Jan Evert
Jan Evert van Grootheest wrote:
> Hello,
>
> I am having these problems with SubVersion due to a really large
> revision (or two) that's in the repo.
>
> Here's the history:
> There's a tree of files that I once tried to commit. It started to
> transfer the data (printing all those dots), but after a long time it
> reported an error. I think the server committed everything just fine,
> because the tree is there when I browse through it with a web browser.
> However, the client reported an error. Unfortunately, the exact error
> got lost. The WC directory tree for the commit totals some 230Mb.
> The working copy that the committed tree is in, still thinks that the
> add was not committed.
> If I try 'svn status', it reports in 18832 lines things that need to be
> added.
> If I try 'svn status -u' I can see from apache that it does a lot of
> things for a while and then one worker shoots up to 99.x% CPU and stays
> there for a long time. At some point in time, the client reports a timeout:
> [issysd25@a05008 current]$ svn st -u
> svn: RA layer request failed
> svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
> svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
> response body (http://a05009:65030)
> All the while, the server is still very busy. These are the relevant
> lines from the apache access log:
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1" 207 758
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/!svn/vcc/default HTTP/1.1" 207 397
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/!svn/bln/16 HTTP/1.1" 207 450
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1"
> 207 769
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "PROPFIND
> /svn/MAL/MAL/Dev/documentation/3rdparty/ACE/current HTTP/1.1" 207 758
> a05008.aex.nl - - [10/Sep/2003:16:53:32 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers
> HTTP/1.1" 207 2802
> a05008.aex.nl - - [10/Sep/2003:16:53:32 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers/html
> HTTP/1.1" 207 11436
> a05008.aex.nl - - [10/Sep/2003:16:53:33 +0200] "PROPFIND
> /svn/MAL/!svn/bc/16/MAL/Dev/documentation/3rdparty/ACE/current/ACE_wrappers/html/tao
> HTTP/1.1" 207 6158346
> a05008.aex.nl - - [10/Sep/2003:16:53:30 +0200] "REPORT
> /svn/MAL/!svn/vcc/default HTTP/1.1" 200 9027147
> Although I cannot guarantee that all these lines are the result of that
> svn status call, the paths in them all relate it. And the number 16 (if
> it is a revision number) matches that really big commit that failed
> client-side that I mentioned above. As you can see, it returns some 15Mb
> in total in the last two lines.
>
> Any comments up till now are welcome.
> As for questions....
> What can I do to make this 'svn status -u' complete (apart from a faster
> server, of course)?
> Will all 'svn status -u' calls in the future have this problem?
>
> What can I do to get this working better? How can I help you to improve
> subversion with regard to this problem? I will not be able to do
> extensive debugging, although investing a limited amount of time is no
> problem.
> I really would like to improve subversion and not expose the rest of the
> company to this, as there are already some that are not convinced of the
> advantages of svn over source safe (from a project point of view, not
> necessarily technical).
> Since, until now, there is no proprietary code in the repo yet, I could
> mail/make available the database or a dump of it for testing. The db is
> some 374Mb, while the zipped dump is still close to 60Mb.
> Processing the dump somewhat reports these numbers:
> [switch@a05009 dump]$ wc -l MAL.20030911
> 7258432 MAL.20030911
> [switch@a05009 dump]$ grep -na Revision-number MAL.20030911
> 5:Revision-number: 0
> 15:Revision-number: 1
> 285:Revision-number: 2
> 1939:Revision-number: 3
> 1966:Revision-number: 4
> 2585:Revision-number: 5
> 3204:Revision-number: 6
> 3806:Revision-number: 7
> 4407:Revision-number: 8
> 5042:Revision-number: 9
> 4743620:Revision-number: 10
> 4743645:Revision-number: 11
> 4743670:Revision-number: 12
> 4743702:Revision-number: 13
> 4743724:Revision-number: 14
> 4746521:Revision-number: 15
> 4746558:Revision-number: 16
>
> Thanks,
> Jan Evert
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Philip Martin <ph...@codematters.co.uk>.
Jan Evert van Grootheest <j....@euronext.nl> writes:
> This tree is about 62Mb and contains 6160 files. Of those, 5144 files
> are in one single directory.
> I would expect svn to be able to handle such a large directory.
There has always been a problem using directories with lots of entries
over ra_dav. Things are getting better, issue 773 has been fixed so
the server memory use is under control, but issue 1492 is still open.
The PROPFIND on a large directory can take a long time, and what's
worse is that it doesn't scale very well.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Jan Evert van Grootheest <j....@euronext.nl>.
Ben, others,
I've been doing some testing...
I've already tried importing that failing tree into a fresh db through
Apache. It failed again. I now took the time to check a bit more. It has
inserted all files and the server is at 99.9% CPU. Apparently it is
finishing off the request (committing the transaction?). The client
reports this:
svn: RA layer request failed
svn: MERGE request failed on
'/svn/MAL3/MAL/Dev/documentation/3rdparty/ACE/current'
svn: MERGE of '/svn/MAL3/MAL/Dev/documentation/3rdparty/ACE/current':
timed out waiting for server (http://a05009:65030)
At the bottom are a couple of gdb backtraces in case you'd like to know
what the server is doing.
Now I've just created a new db that is accessed as file:/// and the
first revision is to import the tree of files that failed before.
This tree is about 62Mb and contains 6160 files. Of those, 5144 files
are in one single directory.
The import is still in progress. However, it seems to be slowing down
when going through this large directory. In the beginning it was almost
impossible to read what it was doing as the lines were scrolling along.
Currently, it has slowed to less than 2 lines per second.
And also the CPU load is increasing slowly. It started out around 7% and
has grown to 31% already.
It has now finished that directory and the CPU dropped back to 3-5% and
speed has increased again, but not to what it was in the beginning.
At the end it had read all the files and CPU shot up to 99.9% and stayed
there for some 5 minutes!
I would expect svn to be able to handle such a large directory. It looks
like processing time is increasing with the number of files (entries?)
in a directory... Could that be the culprit here?
Thanks,
Jan Evert
(gdb) bt
#0 0x4207f963 in strchr () from /lib/i686/libc.so.6
#1 0x0ae48460 in ?? ()
#2 0x40359ded in svn_fs__parse_entries_skel (entries_p=0xbffff04c,
skel=0xaccbb90, pool=0xaeaa600)
at subversion/libsvn_fs/util/fs_skels.c:700
#3 0x4034cce9 in get_dir_entries (entries_p=0xbffff0b0, fs=0x8311b80,
noderev=0xad8ddd8, trail=0xacba640)
at subversion/libsvn_fs/dag.c:454
#4 0x4034d256 in svn_fs__dag_dir_entries (entries=0xbffff0b0,
node=0xaeac538, trail=0xacba640)
at subversion/libsvn_fs/dag.c:658
#5 0x4034cde3 in dir_entry_id_from_node (id_p=0xbffff0d8, parent=0xaeac538,
name=0xad8de88 "classACE__Malloc__FIFO__Iterator__T-members.html",
trail=0xacba640)
at subversion/libsvn_fs/dag.c:498
#6 0x4034e6b9 in svn_fs__dag_open (child_p=0xbffff118, parent=0xaeac538,
name=0xad8de88 "classACE__Malloc__FIFO__Iterator__T-members.html",
trail=0xacba640)
at subversion/libsvn_fs/dag.c:1462
#7 0x403547b9 in open_path (parent_path_p=0xbffff164, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Malloc__FIFO__Iterator__T-members.html",
flags=0,
trail=0xacba640) at subversion/libsvn_fs/tree.c:689
#8 0x40354a0d in get_dag (dag_node_p=0xbffff188, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Malloc__FIFO__Iterator__T-members.html",
trail=0xacba640) at subversion/libsvn_fs/tree.c:841
#9 0x40354abc in txn_body_node_id (baton=0xbffff1f0, trail=0xacba640)
at subversion/libsvn_fs/tree.c:893
#10 0x40353ccf in svn_fs__retry_txn (fs=0x8311b80, txn_body=0x40354a90
<txn_body_node_id>, baton=0xbffff1f0,
pool=0xacba5b8) at subversion/libsvn_fs/trail.c:132
#11 0x40354b2c in svn_fs_node_id (id_p=0xbffff23c, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Malloc__FIFO__Iterator__T-members.html",
pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:913
#12 0x40355610 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Malloc__FIFO__Iterator__T-members.html",
txn_id=0x8159190 "1", pool=0xacba5b8) at
subversion/libsvn_fs/tree.c:1480
#13 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8313b88 "/MAL/ACE_wrappers/html/ace",
txn_id=0x8159190 "1", pool=0x8313b50) at
subversion/libsvn_fs/tree.c:1508
#14 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x83b7d18 "/MAL/ACE_wrappers/html",
txn_id=0x8159190 "1", pool=0x83b7ce0) at
subversion/libsvn_fs/tree.c:1508
#15 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8345c28 "/MAL/ACE_wrappers",
txn_id=0x8159190 "1", pool=0x8345bf0) at
subversion/libsvn_fs/tree.c:1508
#16 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8476da8 "/MAL", txn_id=0x8159190 "1",
pool=0x8476d70) at subversion/libsvn_fs/tree.c:1508
#17 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x4035c3de "/", txn_id=0x8159190 "1",
pool=0x8158f88) at subversion/libsvn_fs/tree.c:1508
#18 0x403568af in svn_fs_commit_txn (conflict_p=0xbffff580,
new_rev=0xbffff584, txn=0x8158fc0)
at subversion/libsvn_fs/tree.c:2469
#19 0x403386b6 in svn_repos_fs_commit_txn (conflict_p=0xbffff580,
repos=0x8131f88, new_rev=0xbffff584,
txn=0x8158fc0) at subversion/libsvn_repos/fs-wrap.c:54
#20 0x4032be34 in dav_svn_merge (target=0x834f178, source=0x836cde0,
no_auto_merge=1, no_checkout=1,
prop_elem=0x834ef20, output=0x8366930) at
./subversion/mod_dav_svn/version.c:877
#21 0x402ca7d5 in dav_method_merge (r=0x8365ca8) at mod_dav.c:4318
#22 0x08066bba in ap_run_handler ()
#23 0x080670d5 in ap_invoke_handler ()
#24 0x08064477 in ap_process_request ()
#25 0x080605c8 in ap_process_http_connection ()
#26 0x0806e9b2 in ap_run_process_connection ()
#27 0x0806586d in child_main ()
#28 0x080659b4 in make_child ()
#29 0x08065b6a in perform_idle_server_maintenance ()
#30 0x08065efa in ap_mpm_run ()
#31 0x0806afaf in main ()
#32 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) bt
#0 0x40350805 in svn_fs_parse_id (
data=0x40ed74c0 "3cj.0.1) (FILE__Connector_8cpp__incl.png sw.0.1)
(Recyclable_8h.html 7 1e8.0.1) (classACE__Null__Semaphore-members.html 7
309.0.1) (Dynamic__Service__Base_8i.html qo.0.1)
(inherit__graph__219.png 7 47"...,
data_len=7, pool=0xaf05c38) at subversion/libsvn_fs/id.c:140
#1 0x40359ded in svn_fs__parse_entries_skel (entries_p=0xbffff08c,
skel=0xaf48e38, pool=0xaf05c38)
at subversion/libsvn_fs/util/fs_skels.c:700
#2 0x4034cce9 in get_dir_entries (entries_p=0xbffff0f0, fs=0x8311b80,
noderev=0xaeffc08, trail=0xacba658)
at subversion/libsvn_fs/dag.c:454
#3 0x4034d256 in svn_fs__dag_dir_entries (entries=0xbffff0f0,
node=0xaf07b60, trail=0xacba658)
at subversion/libsvn_fs/dag.c:658
#4 0x4034cde3 in dir_entry_id_from_node (id_p=0xbffff118, parent=0xaf07b60,
name=0xaeffcb8 "OS__String_8h__dep__incl.png", trail=0xacba658) at
subversion/libsvn_fs/dag.c:498
#5 0x4034e6b9 in svn_fs__dag_open (child_p=0xbffff158, parent=0xaf07b60,
name=0xaeffcb8 "OS__String_8h__dep__incl.png", trail=0xacba658) at
subversion/libsvn_fs/dag.c:1462
#6 0x403547b9 in open_path (parent_path_p=0xbffff1a4, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/OS__String_8h__dep__incl.png", flags=0,
trail=0xacba658)
at subversion/libsvn_fs/tree.c:689
#7 0x40354a0d in get_dag (dag_node_p=0xbffff1c8, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/OS__String_8h__dep__incl.png", trail=0xacba658)
at subversion/libsvn_fs/tree.c:841
#8 0x4035557c in txn_body_txn_deltify (baton=0xbffff240,
trail=0xacba658) at subversion/libsvn_fs/tree.c:1451
#9 0x40353ccf in svn_fs__retry_txn (fs=0x8311b80, txn_body=0x40355550
<txn_body_txn_deltify>, baton=0xbffff240,
pool=0xacba5b8) at subversion/libsvn_fs/trail.c:132
#10 0x40355761 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/OS__String_8h__dep__incl.png",
txn_id=0x8159190 "1",
pool=0xacba5b8) at subversion/libsvn_fs/tree.c:1522
#11 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8313b88 "/MAL/ACE_wrappers/html/ace",
txn_id=0x8159190 "1", pool=0x8313b50) at
subversion/libsvn_fs/tree.c:1508
#12 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x83b7d18 "/MAL/ACE_wrappers/html",
txn_id=0x8159190 "1", pool=0x83b7ce0) at
subversion/libsvn_fs/tree.c:1508
#13 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8345c28 "/MAL/ACE_wrappers",
txn_id=0x8159190 "1", pool=0x8345bf0) at
subversion/libsvn_fs/tree.c:1508
#14 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8476da8 "/MAL", txn_id=0x8159190 "1",
pool=0x8476d70) at subversion/libsvn_fs/tree.c:1508
#15 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x4035c3de "/", txn_id=0x8159190 "1",
pool=0x8158f88) at subversion/libsvn_fs/tree.c:1508
#16 0x403568af in svn_fs_commit_txn (conflict_p=0xbffff580,
new_rev=0xbffff584, txn=0x8158fc0)
at subversion/libsvn_fs/tree.c:2469
#17 0x403386b6 in svn_repos_fs_commit_txn (conflict_p=0xbffff580,
repos=0x8131f88, new_rev=0xbffff584,
txn=0x8158fc0) at subversion/libsvn_repos/fs-wrap.c:54
#18 0x4032be34 in dav_svn_merge (target=0x834f178, source=0x836cde0,
no_auto_merge=1, no_checkout=1,
prop_elem=0x834ef20, output=0x8366930) at
./subversion/mod_dav_svn/version.c:877
#19 0x402ca7d5 in dav_method_merge (r=0x8365ca8) at mod_dav.c:4318
#20 0x08066bba in ap_run_handler ()
#21 0x080670d5 in ap_invoke_handler ()
#22 0x08064477 in ap_process_request ()
#23 0x080605c8 in ap_process_http_connection ()
#24 0x0806e9b2 in ap_run_process_connection ()
#25 0x0806586d in child_main ()
#26 0x080659b4 in make_child ()
#27 0x08065b6a in perform_idle_server_maintenance ()
#28 0x08065efa in ap_mpm_run ()
#29 0x0806afaf in main ()
#30 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) bt
#0 0x420d8d9a in pread64 () from /lib/i686/libc.so.6
#1 0x401a9076 in __os_io () from
/home/switch/svn/svn-generic/lib/libdb-4.0.so
#2 0x401a2920 in __memp_pgread () from
/home/switch/svn/svn-generic/lib/libdb-4.0.so
#3 0x401a3767 in __memp_fget () from
/home/switch/svn/svn-generic/lib/libdb-4.0.so
#4 0x40151f8a in __bam_c_next () from
/home/switch/svn/svn-generic/lib/libdb-4.0.so
#5 0x4014fe83 in __bam_c_get () from
/home/switch/svn/svn-generic/lib/libdb-4.0.so
#6 0x4016e843 in __db_c_get () from
/home/switch/svn/svn-generic/lib/libdb-4.0.so
#7 0x4034b1b9 in get_next_length (length=0xbfffee88, cursor=0x81540e8,
query=0xbfffee90)
at subversion/libsvn_fs/bdb/strings-table.c:142
#8 0x4034b7c4 in svn_fs__bdb_string_size (size=0xbfffef18,
fs=0x8311b80, key=0xb2268c0 "3", trail=0xb0cc2d0)
at subversion/libsvn_fs/bdb/strings-table.c:386
#9 0x40351ac7 in svn_fs__rep_contents_size (size_p=0xbfffef18,
fs=0x8311b80, rep_key=0xb226718 "3",
trail=0xb0cc2d0) at subversion/libsvn_fs/reps-strings.c:666
#10 0x40351bc2 in svn_fs__rep_contents (str=0xbfffefe0, fs=0x8311b80,
rep_key=0xb226718 "3", trail=0xb0cc2d0)
at subversion/libsvn_fs/reps-strings.c:716
#11 0x4034ccac in get_dir_entries (entries_p=0xbffff040, fs=0x8311b80,
noderev=0xb2266c0, trail=0xb0cc2d0)
at subversion/libsvn_fs/dag.c:447
#12 0x4034d256 in svn_fs__dag_dir_entries (entries=0xbffff040,
node=0xb2265a0, trail=0xb0cc2d0)
at subversion/libsvn_fs/dag.c:658
#13 0x4034cde3 in dir_entry_id_from_node (id_p=0xbffff068,
parent=0xb2265a0, name=0xb226760 "ace",
trail=0xb0cc2d0) at subversion/libsvn_fs/dag.c:498
#14 0x4034e6b9 in svn_fs__dag_open (child_p=0xbffff0a8,
parent=0xb2265a0, name=0xb226760 "ace", trail=0xb0cc2d0)
at subversion/libsvn_fs/dag.c:1462
#15 0x403547b9 in open_path (parent_path_p=0xbffff0f4, root=0x82e6ad8,
path=0xb0cc2a0 "/MAL/ACE_wrappers/html/ace/QoS/graph_legend.png",
flags=0, trail=0xb0cc2d0)
at subversion/libsvn_fs/tree.c:689
#16 0x40354a0d in get_dag (dag_node_p=0xbffff118, root=0x82e6ad8,
path=0xb0cc2a0 "/MAL/ACE_wrappers/html/ace/QoS/graph_legend.png",
trail=0xb0cc2d0)
at subversion/libsvn_fs/tree.c:841
#17 0x40354abc in txn_body_node_id (baton=0xbffff180, trail=0xb0cc2d0)
at subversion/libsvn_fs/tree.c:893
#18 0x40353ccf in svn_fs__retry_txn (fs=0x8311b80, txn_body=0x40354a90
<txn_body_node_id>, baton=0xbffff180,
pool=0xb0cc268) at subversion/libsvn_fs/trail.c:132
#19 0x40354b2c in svn_fs_node_id (id_p=0xbffff1cc, root=0x82e6ad8,
path=0xb0cc2a0 "/MAL/ACE_wrappers/html/ace/QoS/graph_legend.png",
pool=0xb0cc268)
at subversion/libsvn_fs/tree.c:913
#20 0x40355610 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0xb0cc2a0 "/MAL/ACE_wrappers/html/ace/QoS/graph_legend.png",
txn_id=0x8159190 "1", pool=0xb0cc268)
at subversion/libsvn_fs/tree.c:1480
#21 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0xacba5f0 "/MAL/ACE_wrappers/html/ace/QoS", txn_id=0x8159190
"1", pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:1508
#22 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8313b88 "/MAL/ACE_wrappers/html/ace",
txn_id=0x8159190 "1", pool=0x8313b50) at
subversion/libsvn_fs/tree.c:1508
#23 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x83b7d18 "/MAL/ACE_wrappers/html",
txn_id=0x8159190 "1", pool=0x83b7ce0) at
subversion/libsvn_fs/tree.c:1508
#24 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8345c28 "/MAL/ACE_wrappers",
txn_id=0x8159190 "1", pool=0x8345bf0) at
subversion/libsvn_fs/tree.c:1508
#25 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8476da8 "/MAL", txn_id=0x8159190 "1",
pool=0x8476d70) at subversion/libsvn_fs/tree.c:1508
#26 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x4035c3de "/", txn_id=0x8159190 "1",
pool=0x8158f88) at subversion/libsvn_fs/tree.c:1508
#27 0x403568af in svn_fs_commit_txn (conflict_p=0xbffff580,
new_rev=0xbffff584, txn=0x8158fc0)
at subversion/libsvn_fs/tree.c:2469
#28 0x403386b6 in svn_repos_fs_commit_txn (conflict_p=0xbffff580,
repos=0x8131f88, new_rev=0xbffff584,
txn=0x8158fc0) at subversion/libsvn_repos/fs-wrap.c:54
#29 0x4032be34 in dav_svn_merge (target=0x834f178, source=0x836cde0,
no_auto_merge=1, no_checkout=1,
prop_elem=0x834ef20, output=0x8366930) at
./subversion/mod_dav_svn/version.c:877
#30 0x402ca7d5 in dav_method_merge (r=0x8365ca8) at mod_dav.c:4318
#31 0x08066bba in ap_run_handler ()
#32 0x080670d5 in ap_invoke_handler ()
#33 0x08064477 in ap_process_request ()
#34 0x080605c8 in ap_process_http_connection ()
#35 0x0806e9b2 in ap_run_process_connection ()
#36 0x0806586d in child_main ()
#37 0x080659b4 in make_child ()
#38 0x08065b6a in perform_idle_server_maintenance ()
#39 0x08065efa in ap_mpm_run ()
#40 0x0806afaf in main ()
#41 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) bt
#0 0x401f35ee in find_entry (ht=0xae23b18, key=0xaeb64f8, klen=24,
val=0xae1fff8) at apr_hash.c:279
#1 0x401f37ac in apr_hash_set (ht=0xae23b18, key=0xaeb64f8, klen=24,
val=0xae1fff8) at apr_hash.c:353
#2 0x4034cd9b in get_dir_entries (entries_p=0xbffff040, fs=0x8311b80,
noderev=0xae3b4e8, trail=0xacba648)
at subversion/libsvn_fs/dag.c:477
#3 0x4034d256 in svn_fs__dag_dir_entries (entries=0xbffff040,
node=0xad28b20, trail=0xacba648)
at subversion/libsvn_fs/dag.c:658
#4 0x4034cde3 in dir_entry_id_from_node (id_p=0xbffff068, parent=0xad28b20,
name=0xae3b598 "classACE__Auto__Array__Ptr__coll__graph.png",
trail=0xacba648)
at subversion/libsvn_fs/dag.c:498
#5 0x4034e6b9 in svn_fs__dag_open (child_p=0xbffff0a8, parent=0xad28b20,
name=0xae3b598 "classACE__Auto__Array__Ptr__coll__graph.png",
trail=0xacba648)
at subversion/libsvn_fs/dag.c:1462
#6 0x403547b9 in open_path (parent_path_p=0xbffff0f4, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Auto__Array__Ptr__coll__graph.png",
flags=0,
trail=0xacba648) at subversion/libsvn_fs/tree.c:689
#7 0x40354a0d in get_dag (dag_node_p=0xbffff118, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Auto__Array__Ptr__coll__graph.png",
trail=0xacba648)
at subversion/libsvn_fs/tree.c:841
#8 0x40354abc in txn_body_node_id (baton=0xbffff180, trail=0xacba648)
at subversion/libsvn_fs/tree.c:893
#9 0x40353ccf in svn_fs__retry_txn (fs=0x8311b80, txn_body=0x40354a90
<txn_body_node_id>, baton=0xbffff180,
pool=0xacba5b8) at subversion/libsvn_fs/trail.c:132
#10 0x40354b2c in svn_fs_node_id (id_p=0xbffff1bc, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Auto__Array__Ptr__coll__graph.png",
pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:913
#11 0x40354c89 in node_kind (kind_p=0xbffff204, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Auto__Array__Ptr__coll__graph.png",
pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:986
#12 0x40354d5b in svn_fs_is_dir (is_dir=0xbffff238, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Auto__Array__Ptr__coll__graph.png",
pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:1025
#13 0x40355656 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0xacba5f0
"/MAL/ACE_wrappers/html/ace/classACE__Auto__Array__Ptr__coll__graph.png",
txn_id=0x8159190 "1", pool=0xacba5b8) at
subversion/libsvn_fs/tree.c:1490
#14 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8313b88 "/MAL/ACE_wrappers/html/ace",
txn_id=0x8159190 "1", pool=0x8313b50) at
subversion/libsvn_fs/tree.c:1508
#15 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x83b7d18 "/MAL/ACE_wrappers/html",
txn_id=0x8159190 "1", pool=0x83b7ce0) at
subversion/libsvn_fs/tree.c:1508
#16 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8345c28 "/MAL/ACE_wrappers",
txn_id=0x8159190 "1", pool=0x8345bf0) at
subversion/libsvn_fs/tree.c:1508
#17 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8476da8 "/MAL", txn_id=0x8159190 "1",
pool=0x8476d70) at subversion/libsvn_fs/tree.c:1508
#18 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x4035c3de "/", txn_id=0x8159190 "1",
pool=0x8158f88) at subversion/libsvn_fs/tree.c:1508
#19 0x403568af in svn_fs_commit_txn (conflict_p=0xbffff580,
new_rev=0xbffff584, txn=0x8158fc0)
at subversion/libsvn_fs/tree.c:2469
#20 0x403386b6 in svn_repos_fs_commit_txn (conflict_p=0xbffff580,
repos=0x8131f88, new_rev=0xbffff584,
txn=0x8158fc0) at subversion/libsvn_repos/fs-wrap.c:54
#21 0x4032be34 in dav_svn_merge (target=0x834f178, source=0x836cde0,
no_auto_merge=1, no_checkout=1,
prop_elem=0x834ef20, output=0x8366930) at
./subversion/mod_dav_svn/version.c:877
#22 0x402ca7d5 in dav_method_merge (r=0x8365ca8) at mod_dav.c:4318
#23 0x08066bba in ap_run_handler ()
#24 0x080670d5 in ap_invoke_handler ()
#25 0x08064477 in ap_process_request ()
#26 0x080605c8 in ap_process_http_connection ()
#27 0x0806e9b2 in ap_run_process_connection ()
#28 0x0806586d in child_main ()
#29 0x080659b4 in make_child ()
#30 0x08065b6a in perform_idle_server_maintenance ()
#31 0x08065efa in ap_mpm_run ()
#32 0x0806afaf in main ()
#33 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) bt
#0 list (
data=0x40e4c020 "((classACE__Lite__MMAP__Memory__Pool-members.html
7 2q0.0.1) (classACE__Stream__inherit__graph.png 7 3kp.0.1)
(Token__Collection_8cpp__incl.png 7 1v0.0.1) (inherit__graph__40.png 7
426.0.1) (Unbounded"...,
len=237498, pool=0xacd2aa0) at subversion/libsvn_fs/util/skel.c:144
#1 0x4034ccce in get_dir_entries (entries_p=0xbffff0b0, fs=0x8311b80,
noderev=0xadf93c8, trail=0xacba620)
at subversion/libsvn_fs/dag.c:449
#2 0x4034d256 in svn_fs__dag_dir_entries (entries=0xbffff0b0,
node=0xacd49b8, trail=0xacba620)
at subversion/libsvn_fs/dag.c:658
#3 0x4034cde3 in dir_entry_id_from_node (id_p=0xbffff0d8, parent=0xacd49b8,
name=0xadf9478 "Atomic__Op_8i.html", trail=0xacba620) at
subversion/libsvn_fs/dag.c:498
#4 0x4034e6b9 in svn_fs__dag_open (child_p=0xbffff118,
parent=0xacd49b8, name=0xadf9478 "Atomic__Op_8i.html",
trail=0xacba620) at subversion/libsvn_fs/dag.c:1462
#5 0x403547b9 in open_path (parent_path_p=0xbffff164, root=0x82e6ad8,
path=0xacba5f0 "/MAL/ACE_wrappers/html/ace/Atomic__Op_8i.html",
flags=0, trail=0xacba620)
at subversion/libsvn_fs/tree.c:689
#6 0x40354a0d in get_dag (dag_node_p=0xbffff188, root=0x82e6ad8,
path=0xacba5f0 "/MAL/ACE_wrappers/html/ace/Atomic__Op_8i.html",
trail=0xacba620)
at subversion/libsvn_fs/tree.c:841
#7 0x40354abc in txn_body_node_id (baton=0xbffff1f0, trail=0xacba620)
at subversion/libsvn_fs/tree.c:893
#8 0x40353ccf in svn_fs__retry_txn (fs=0x8311b80, txn_body=0x40354a90
<txn_body_node_id>, baton=0xbffff1f0,
pool=0xacba5b8) at subversion/libsvn_fs/trail.c:132
#9 0x40354b2c in svn_fs_node_id (id_p=0xbffff23c, root=0x82e6ad8,
path=0xacba5f0 "/MAL/ACE_wrappers/html/ace/Atomic__Op_8i.html",
pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:913
#10 0x40355610 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0xacba5f0 "/MAL/ACE_wrappers/html/ace/Atomic__Op_8i.html",
txn_id=0x8159190 "1", pool=0xacba5b8)
at subversion/libsvn_fs/tree.c:1480
#11 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8313b88 "/MAL/ACE_wrappers/html/ace",
txn_id=0x8159190 "1", pool=0x8313b50) at
subversion/libsvn_fs/tree.c:1508
#12 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x83b7d18 "/MAL/ACE_wrappers/html",
txn_id=0x8159190 "1", pool=0x83b7ce0) at
subversion/libsvn_fs/tree.c:1508
#13 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8345c28 "/MAL/ACE_wrappers",
txn_id=0x8159190 "1", pool=0x8345bf0) at
subversion/libsvn_fs/tree.c:1508
#14 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x8476da8 "/MAL", txn_id=0x8159190 "1",
pool=0x8476d70) at subversion/libsvn_fs/tree.c:1508
#15 0x40355704 in deltify_mutable (fs=0x8311b80, root=0x82e6ad8,
path=0x4035c3de "/", txn_id=0x8159190 "1",
pool=0x8158f88) at subversion/libsvn_fs/tree.c:1508
#16 0x403568af in svn_fs_commit_txn (conflict_p=0xbffff580,
new_rev=0xbffff584, txn=0x8158fc0)
at subversion/libsvn_fs/tree.c:2469
#17 0x403386b6 in svn_repos_fs_commit_txn (conflict_p=0xbffff580,
repos=0x8131f88, new_rev=0xbffff584,
txn=0x8158fc0) at subversion/libsvn_repos/fs-wrap.c:54
#18 0x4032be34 in dav_svn_merge (target=0x834f178, source=0x836cde0,
no_auto_merge=1, no_checkout=1,
prop_elem=0x834ef20, output=0x8366930) at
./subversion/mod_dav_svn/version.c:877
#19 0x402ca7d5 in dav_method_merge (r=0x8365ca8) at mod_dav.c:4318
#20 0x08066bba in ap_run_handler ()
#21 0x080670d5 in ap_invoke_handler ()
#22 0x08064477 in ap_process_request ()
#23 0x080605c8 in ap_process_http_connection ()
#24 0x0806e9b2 in ap_run_process_connection ()
#25 0x0806586d in child_main ()
#26 0x080659b4 in make_child ()
#27 0x08065b6a in perform_idle_server_maintenance ()
#28 0x08065efa in ap_mpm_run ()
#29 0x0806afaf in main ()
#30 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) q
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Jan Evert van Grootheest <j....@euronext.nl>.
The first large revision (rev 9) in that repo is this:
[issysd25@a05008 ACE]$ du -sx *
477568 ACE_wrappers
[issysd25@a05008 ACE]$ find . -type f | wc -l
26978
The second one (rev 16, that's causing the problems) is this:
[issysd25@a05008 current]$ du -sx .
230572 .
[issysd25@a05008 current]$ find . -type f | wc -l
28525
Other than sharing the same repo, these two large revisions are in
totally separate directory trees.
-- Jan Evert
Ben Collins-Sussman wrote:
> Jan Evert van Grootheest <j....@euronext.nl> writes:
>
>
>>Ben,
>>
>>I just tried to checkout to a fresh directory:
>>
>>time svn co http://a05009:65030/svn/MAL/MAL/Dev/documentation .
>> < snip reports for 858 files >
>>svn: RA layer request failed
>>svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
>>svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
>>response body (http://a05009:65030)
>
>
> This looks like a problem with Apache... very strange.
>
> How big did you say the tree was?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Ben Collins-Sussman <su...@collab.net>.
Jan Evert van Grootheest <j....@euronext.nl> writes:
> Ben,
>
> I just tried to checkout to a fresh directory:
>
> time svn co http://a05009:65030/svn/MAL/MAL/Dev/documentation .
> < snip reports for 858 files >
> svn: RA layer request failed
> svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
> svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
> response body (http://a05009:65030)
This looks like a problem with Apache... very strange.
How big did you say the tree was?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Jan Evert van Grootheest <j....@euronext.nl>.
Ben,
I just tried to checkout to a fresh directory:
time svn co http://a05009:65030/svn/MAL/MAL/Dev/documentation .
< snip reports for 858 files >
svn: RA layer request failed
svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
response body (http://a05009:65030)
real 13m8.838s
user 0m1.350s
sys 0m0.320s
After this failure I tried updating that:
[issysd25@a05008 documentation]$ time svn up
svn: RA layer request failed
svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
svn: REPORT of '/svn/MAL/!svn/vcc/default': timed out waiting for server
(http://a05009:65030)
real 2m0.658s
user 0m0.030s
sys 0m0.020s
I'll figure a way to get it to you... we do not ahve direct internet
access here. Only mail.
If there's a place I could upload it, I'd have to burn it to a CD, then
upload it to you. Otherwise I don't know where to put it.
-- Jan Evert
Ben Collins-Sussman wrote:
> Jan Evert van Grootheest <j....@euronext.nl> writes:
>
>
>>I think the server committed everything just fine, because the tree
>>is there when I browse through it with a web browser. However, the
>>client reported an error. Unfortunately, the exact error got lost.
>
>
> If we don't know the error, it's hard for us to figure out what went
> wrong.
>
>
>
>>The working copy that the committed tree is in, still thinks that the
>>add was not committed.
>
>
> Not a surprise. There was probably some error when the working copy
> was parsing the "result" of the commit. Just throw away the working
> copy, and check out a new one.
>
>
>>[issysd25@a05008 current]$ svn st -u
>>svn: RA layer request failed
>>svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
>>svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
>>response body (http://a05009:65030)
>
>
> "Error reading response body?" That's pretty strange.
>
> If you can give us a copy of the repository, maybe we can try to
> reproduce the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: large revision causes problems
Posted by Ben Collins-Sussman <su...@collab.net>.
Jan Evert van Grootheest <j....@euronext.nl> writes:
> I think the server committed everything just fine, because the tree
> is there when I browse through it with a web browser. However, the
> client reported an error. Unfortunately, the exact error got lost.
If we don't know the error, it's hard for us to figure out what went
wrong.
> The working copy that the committed tree is in, still thinks that the
> add was not committed.
Not a surprise. There was probably some error when the working copy
was parsing the "result" of the commit. Just throw away the working
copy, and check out a new one.
> [issysd25@a05008 current]$ svn st -u
> svn: RA layer request failed
> svn: REPORT request failed on '/svn/MAL/!svn/vcc/default'
> svn: REPORT of '/svn/MAL/!svn/vcc/default': Error reading chunked
> response body (http://a05009:65030)
"Error reading response body?" That's pretty strange.
If you can give us a copy of the repository, maybe we can try to
reproduce the problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org