You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Øyvind A. Holm" <su...@sunbase.org> on 2004/06/21 19:23:52 UTC
Bug: Problems committing special revisions
This is episode #2 of the “many revisions in svn” experiment I have
running on one of my machines. I have mentioned this in the message
“Bug: svn-1.0.4 stops at 65536 revisions” dated 2004-05-28
16:34:45+0200, also fund at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=67597
The message is about this script running in a loop updating a file and
committing it. The script has runned more or less continuous since
2004-05-28 20:15:22 GMT, only interrupted because svn had some problems
commiting some special revisions. Until now, these revisions has created
problems:
65536
262144 (4*65536)
786432 (12*65536)
1048576 (16*65536)
1310720 (20*65536)
It is currently at r1554955, the next potential trouble comes at
r1572864 (24*65536) if it follows the habit.
First of all, some info about the environment:
Debian GNU/Linux 3.0 (woody)
gcc-2.95.4
ldd (GNU libc) 2.2.5
Apache-2.0.49
svn-1.0.4 (Yes, I know)
This is what happens:
======== {{{ ========
Transmitting file data .
Committed revision 786430.
Sending f
Transmitting file data .
Committed revision 786431.
Sending f
Transmitting file data ./home/sunny/src/svn/test/trunk/svn-stressing/mange: line 11: 16669 Aborted svn ci -m "1" f
svn: Working copy '/root/mange/many2' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: Working copy '/root/mange/many2' locked
======== }}} ========
The working copy is now locked, and a svn cleanup is required. In
addition, an svn update is necessary to do the next commit. The file is
often modified at this point, though that is a random condition, as the
file content alternates between '0' and '1'. It seems as svn dies after
it has commited the file, but before it updates the working copy.
When I now try to commit the change into the repository, svn grows to
around 730 megabytes in the memory and then dies. (When committing
r262144 svn left a core dump of 1.619.374.080 bytes and died.) A new svn
cleanup is necessary. After this commit is done, all commits happens
normally.
strace dumps for commits around r65536 and a dump file containing 65533
revisions for further testing is located at
http://tmp.sunbase.org/svnbug/many-revisions/
Regards,
Øyvind A. Holm
---------------------
cat /dev/urandom >SCO
[PATCH] Re: Bug: Problems committing special revisions
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Tobias Ringström wrote:
> ...but it's also horribly wrong because pred_id is a pointer which I
> didn't realize when I wrote it. I'm surprised that it didn't crash.
Please try the following patch instead. I'll commit it shortly unless
there are any objections.
/Tobias
[[[
Fix the excessive memory usage when deltifying revision 2^n where n is
large.
* subversion/libsvn_fs_base/tree.c
(deltify_mutable): Introduce two alternating subpools.
]]]
Re: Bug: Problems committing special revisions
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Tobias Ringström wrote:
> I just took a quick look, but the following patch should take care of
> the extreme memory usage you've been experiencing.
...but it's also horribly wrong because pred_id is a pointer which I
didn't realize when I wrote it. I'm surprised that it didn't crash.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug: Problems committing special revisions
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Øyvind A. Holm wrote:
>When I now try to commit the change into the repository, svn grows to
>around 730 megabytes in the memory and then dies. (When committing
>r262144 svn left a core dump of 1.619.374.080 bytes and died.) A new svn
>cleanup is necessary. After this commit is done, all commits happens
>normally.
>
I just took a quick look, but the following patch should take care of
the extreme memory usage you've been experiencing.
/Tobias
Index: subversion/libsvn_fs_base/tree.c
===================================================================
--- subversion/libsvn_fs_base/tree.c (revision 10049)
+++ subversion/libsvn_fs_base/tree.c (working copy)
@@ -1666,6 +1666,8 @@
pred_id = id;
for (lev = 0; lev < nlevels; lev++)
{
+ apr_pool_t *subpool;
+
/* To save overhead, skip the second level (that is, never
redeltify the node-revision two predecessors back). */
if (lev == 1)
@@ -1674,14 +1676,16 @@
/* Note that COUNT is not reset between levels, and neither is
PREDNODE; we just keep counting from where we were up to
where we're supposed to get. */
+ subpool = svn_pool_create (pool);
while (count < (1 << lev))
{
struct txn_pred_id_args tpi_args;
+ svn_pool_clear (subpool);
tpi_args.id = pred_id;
- tpi_args.pool = pool;
+ tpi_args.pool = subpool;
SVN_ERR (svn_fs_base__retry_txn (fs, txn_body_pred_id,
- &tpi_args, pool));
+ &tpi_args, subpool));
pred_id = tpi_args.pred_id;
if (pred_id == NULL)
@@ -1690,6 +1694,7 @@
count++;
}
+ svn_pool_destroy (subpool);
/* Finally, do the deltification. */
td_args.tgt_id = pred_id;
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org