You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2005/07/01 20:40:12 UTC
svn 1.2.1 tarballs are up for testing/voting
Ben Reser has posted 1.2.1 tarballs.
Committers: please test, vote, and send your sigs!
Non-committers: please test anyway. :-)
Hopefully we'll see a final 1.2.1 release in the next couple of days.
Tarballs are up at http://fornix.brain.org/subversion/
-rw-rw-r-- 1 svnrm svnrm 7226600 Jul 1 16:19 subversion-1.2.1.tar.bz2
-rw-rw-r-- 1 svnrm svnrm 8847778 Jul 1 16:19 subversion-1.2.1.tar.gz
-rw-rw-r-- 1 svnrm svnrm 11683706 Jul 1 16:23 subversion-1.2.1.zip
md5sums:
0b546195ca794c327c6830f2e88661f7 subversion-1.2.1.tar.bz2
01c3742745d50d4395684a4fb2908c5f subversion-1.2.1.tar.gz
75d64c693a41520073e841854a16ed49 subversion-1.2.1.zip
sha1sums:
fbd3364dcbe576bfbb2e7c0baa241c0329 57ad45 subversion-1.2.1.tar.bz2
88d3dd6e8c191933c8966faa5c69dc4ee8 4411cf subversion-1.2.1.tar.gz
2e08f44048549cf64fe4c881bc2319161e 04e60c subversion-1.2.1.zip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.1 tarballs are up for testing/voting
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-07-01 15:40-0500, Ben Collins-Sussman wrote:
> Ben Reser has posted 1.2.1 tarballs.
>
> Committers: please test, vote, and send your sigs!
I have tested the tar balls with following:
- {fsfs, bdb} x {local, svn, http}
- perl bindings
- javahl bindings
- python bindings, they compile
My stress.pl problem is unrelated to 1.2.1, I can reproduce it with
1.1.4, so 1.2.1 is good to go. I have attached my signatures for
gz and bz2.
BR, Jani
--
Jani Averbach
Re: stress.pl errors with ra_dav activity db
Posted by Philip Martin <ph...@codematters.co.uk>.
Jani Averbach <ja...@jaa.iki.fi> writes:
> On 2005-07-05 18:43+0100, Philip Martin wrote:
>> Jani Averbach <ja...@jaa.iki.fi> writes:
>> > So I would say that something is broken on this trail:
>> >
>> > stress.pl -> mod_dav_svn -> activity -> apr_dbm_* -> (BDB, GDBM) -> BANG!
>>
>> It still looks like a locking problem to me, and it's quite possible
>> that mod_dav_svn and libsvn_fs_base exercise different paths through
>> BDB, after all mod_dav_svn doesn't use BDB's transactional interface.
>>
>> So I'd still suggest running the BDB regression tests (and note there
>> are some configure options that affect BDB locking).
>
> I have run the full regression test of BDB 3.4.28 (run_all), which
> took several days to finish and I got five regressions, which all of
> them were these: 'overflow returned error value 1'. So I would guess
> that BDB should be and is working here. Specifically all mutex and
> lock tests worked. I have also also tried to run BDB with following
> mutexes: 'POSIX/pthreads/library', 'x86/gcc-assembly' without any
> difference regarding ra_dav 'activity not found' errors.
Tricky. I could not reproduce it, I don't know how many other people
tried. Do you have another machine/OS you could use to see whether it
is platform specific?
As I understand it, I don't know much about DAV, the activity DB maps
activity_ids to Subversion txns and the activity_id gets passed back
and forth between client and server. You can see activities being
created (MKACTIVITY) and destroyed (DELETE) in the httpd access log.
Unfortunately the error log doesn't appear to contain the failing
activity_id, so if you want to track down the bug probably the first
thing to do is to identify the failing activity_id. You might be able
to catch the error in a debugger, or you may need to modify the
mod_dav_svn code.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl errors with ra_dav activity db
Posted by Jani Averbach <ja...@jaa.iki.fi>.
Hello,
Here is a summary for this problem:
http://svn.haxx.se/dev/archive-2005-07/0130.shtml
and the start of this thread is here:
http://svn.haxx.se/dev/archive-2005-07/0056.shtml
On 2005-07-05 18:43+0100, Philip Martin wrote:
> Jani Averbach <ja...@jaa.iki.fi> writes:
> > So I would say that something is broken on this trail:
> >
> > stress.pl -> mod_dav_svn -> activity -> apr_dbm_* -> (BDB, GDBM) -> BANG!
>
> It still looks like a locking problem to me, and it's quite possible
> that mod_dav_svn and libsvn_fs_base exercise different paths through
> BDB, after all mod_dav_svn doesn't use BDB's transactional interface.
>
> So I'd still suggest running the BDB regression tests (and note there
> are some configure options that affect BDB locking).
I have run the full regression test of BDB 3.4.28 (run_all), which
took several days to finish and I got five regressions, which all of
them were these: 'overflow returned error value 1'. So I would guess
that BDB should be and is working here. Specifically all mutex and
lock tests worked. I have also also tried to run BDB with following
mutexes: 'POSIX/pthreads/library', 'x86/gcc-assembly' without any
difference regarding ra_dav 'activity not found' errors.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs
Posted by Philip Martin <ph...@codematters.co.uk>.
Jani Averbach <ja...@jaa.iki.fi> writes:
> On 2005-07-05 17:06+0100, Philip Martin wrote:
>> Jani Averbach <ja...@jaa.iki.fi> writes:
>>
>> It looks like the locking provided by BDB/GDBM doesn't work on your
>> system--so it's a kernel/filesystem/libc/compiler problem, but I don't
>> know which :)
>
> Sorry to be unclear, but If I run the stress.pl against BDB(4.3)
> backend repository (I double checked that bdb is what I am really
> using),
Ahh, I didn't realise that, I thought you were using fsfs.
> it works just fine with __ra_svn__. If I use ra_dav, it fails
> immediately with activity related errors. So the general locking
> should work, because 10 instances of stress.pl against BDB works just
> fine.
>
> So I would say that something is broken on this trail:
>
> stress.pl -> mod_dav_svn -> activity -> apr_dbm_* -> (BDB, GDBM) -> BANG!
It still looks like a locking problem to me, and it's quite possible
that mod_dav_svn and libsvn_fs_base exercise different paths through
BDB, after all mod_dav_svn doesn't use BDB's transactional interface.
So I'd still suggest running the BDB regression tests (and note there
are some configure options that affect BDB locking).
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-07-05 17:06+0100, Philip Martin wrote:
> Jani Averbach <ja...@jaa.iki.fi> writes:
>
> > So it looks like that here only SDBM works as activity backend.
>
> As far as I know SDBM is very simple and doesn't do any locking, so
> the apr-util wrappers have to do it. BDB, and I think GDBM, provide
> their own locking.
>
> > With
> > anything else, first activity error pops up during the 10-20 first
> > commit. However, this very same system (chroot) compiles and runs
> > nightly regression tests, so it can't be completely nuts.
>
> The Subversion regression tests don't do any concurrent database
> access, so they won't trigger this problem.
>
> It looks like the locking provided by BDB/GDBM doesn't work on your
> system--so it's a kernel/filesystem/libc/compiler problem, but I don't
> know which :)
Sorry to be unclear, but If I run the stress.pl against BDB(4.3)
backend repository (I double checked that bdb is what I am really
using), it works just fine with __ra_svn__. If I use ra_dav, it fails
immediately with activity related errors. So the general locking
should work, because 10 instances of stress.pl against BDB works just
fine.
So I would say that something is broken on this trail:
stress.pl -> mod_dav_svn -> activity -> apr_dbm_* -> (BDB, GDBM) -> BANG!
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs
Posted by Philip Martin <ph...@codematters.co.uk>.
Jani Averbach <ja...@jaa.iki.fi> writes:
> So it looks like that here only SDBM works as activity backend.
As far as I know SDBM is very simple and doesn't do any locking, so
the apr-util wrappers have to do it. BDB, and I think GDBM, provide
their own locking.
> With
> anything else, first activity error pops up during the 10-20 first
> commit. However, this very same system (chroot) compiles and runs
> nightly regression tests, so it can't be completely nuts.
The Subversion regression tests don't do any concurrent database
access, so they won't trigger this problem.
> Where should I look next, to apr-util, these databases, or mod_dav_svn?
> Used apr-util is 0.9.6.
The BDB source includes extensive regression tests, you could try
running those.
It looks like the locking provided by BDB/GDBM doesn't work on your
system--so it's a kernel/filesystem/libc/compiler problem, but I don't
know which :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-07-03 10:38-0600, Jani Averbach wrote:
> On 2005-07-03 00:49+0100, Philip Martin wrote:
> >
> > That's an error with mod_dav_svn's activity DB, i.e. it's specific to
> > ra_dav. The activity DB uses apr-util's dbm interface, so which
> > backend is being used?
>
> I have tried this with BDB (4.3.27 + 4.3.28) and with gdbm (1.8.3).
> the gdbm was the worst, as an addition those "Activity not found" I got
> lots of errors like: "Could not open activities database".
>
Ok, I have tested this little bit more:
With SDBM, system finished over 8K commits without hitch.
With BDB 4.0, I got these two errors:
svn: Commit failed (details follow):
svn: MERGE request failed on '/stress/repostress/trunk'
svn: Reference to non-existent node '0.0.r-1/-1' in filesystem
'/svnrel/tmp/repostress/db'
and
svn: Commit failed (details follow):
svn: The specified activity does not exist.
With BDB 4.2 or 4.3, I got only this one:
svn: Commit failed (details follow):
svn: The specified activity does not exist.
With GDBM (1.8.3), I got these two:
svn: Commit failed (details follow):
svn: Could not open activities database
and
svn: Commit failed (details follow):
svn: The specified activity does not exist.
So it looks like that here only SDBM works as activity backend. With
anything else, first activity error pops up during the 10-20 first
commit. However, this very same system (chroot) compiles and runs
nightly regression tests, so it can't be completely nuts.
Where should I look next, to apr-util, these databases, or mod_dav_svn?
Used apr-util is 0.9.6.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-07-03 00:49+0100, Philip Martin wrote:
>
> That's an error with mod_dav_svn's activity DB, i.e. it's specific to
> ra_dav. The activity DB uses apr-util's dbm interface, so which
> backend is being used?
I have tried this with BDB (4.3.27 + 4.3.28) and with gdbm (1.8.3).
the gdbm was the worst, as an addition those "Activity not found" I got
lots of errors like: "Could not open activities database".
> Which MPM is Apache using?
Prefork.
> If you pass -d when you invoke stress.pl it will eliminate the client
> status calls. That probably won't make a difference,
Passing -d didn't make any difference.
> I don't have 1.2 at the moment, but I just tried trunk and didn't see
> the problem. I'm using an old dual Pentium3 running Linux 2.4 with
> apr-util/BDB-4.3 and a prefork MPM.
Thanks Philip,
I can reproduce this every time here and very quickly, typically
during first ten or so commits. This happens also with 1.1.4, so
something is very broken here.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs
Posted by Philip Martin <ph...@codematters.co.uk>.
Jani Averbach <ja...@jaa.iki.fi> writes:
> ==> stress.9.log <==
> Sending wcstress.9334/trunk/bar2/foo2
> Sending wcstress.9334/trunk/foo2
> Transmitting file data ....
> Committed revision 41.
> Updating:
> At revision 41.
> Committing:
> unexpected commit fail: exit status: 256
> svn: Commit failed (details follow):
> svn: The specified activity does not exist.
>
> httpd::error_log
> [Sat Jul 02 15:04:34 2005] [error] [client 127.0.0.1] (2)No such file or directory: The specified activity does not exist. [409, #190002]
That's an error with mod_dav_svn's activity DB, i.e. it's specific to
ra_dav. The activity DB uses apr-util's dbm interface, so which
backend is being used?
Which MPM is Apache using?
If you pass -d when you invoke stress.pl it will eliminate the client
status calls. That probably won't make a difference, but if the error
does go away then it indicates that the bug is likely to be in the
status specific code.
> And the Hardware/OS Specs are:
>
> I have repeated this three times in a row, and if I restart testing over
> ra_svn it just keeps going and going. So it doesn't look like that my
> system has just gone nuts.
>
> So, could someone try to reproduce this please? I will attach the script what
> I used for testing.
>
> I used following components for building svn:
> apr-0.9.6
> apr-util-0.9.6
> httpd-2.0.54
> neon-0.24.7
>
> And the Hardware/OS Specs are:
> CPU: SMP amd64 (2x)
> OS: Linux 2.6
> Filesystem: ext3
I don't have 1.2 at the moment, but I just tried trunk and didn't see
the problem. I'm using an old dual Pentium3 running Linux 2.4 with
apr-util/BDB-4.3 and a prefork MPM.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: stress.pl error with ra_dav+fsfs (was: svn 1.2.1 tarballs are up for testing/voting)
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-07-01 15:40-0500, Ben Collins-Sussman wrote:
> Ben Reser has posted 1.2.1 tarballs.
>
> Committers: please test, vote, and send your sigs!
>
I need help:
I tested the tarball successfully over all tests combinations
({fsfs, bdb} x {ra_file, ra_svn, ra_dav}). So far so good.
Then I started stress.pl against installed 1.2.1, and found following:
ra_local (fsfs): ok
ra_svn (fsfs): ok
ra_dav (fsfs): it fails with following error
==> stress.9.log <==
Sending wcstress.9334/trunk/bar2/foo2
Sending wcstress.9334/trunk/foo2
Transmitting file data ....
Committed revision 41.
Updating:
At revision 41.
Committing:
unexpected commit fail: exit status: 256
svn: Commit failed (details follow):
svn: The specified activity does not exist.
httpd::error_log
[Sat Jul 02 15:04:34 2005] [error] [client 127.0.0.1] (2)No such file or directory: The specified activity does not exist. [409, #190002]
I have repeated this three times in a row, and if I restart testing over
ra_svn it just keeps going and going. So it doesn't look like that my
system has just gone nuts.
So, could someone try to reproduce this please? I will attach the script what
I used for testing.
I used following components for building svn:
apr-0.9.6
apr-util-0.9.6
httpd-2.0.54
neon-0.24.7
And the Hardware/OS Specs are:
CPU: SMP amd64 (2x)
OS: Linux 2.6
Filesystem: ext3
BR, Jani
--
Jani Averbach
Re: svn 1.2.1 tarballs are up for testing/voting
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jul 3, 2005, at 10:03 AM, Erik Huelsmann wrote:
>
>
>> Ben Reser has posted 1.2.1 tarballs.
>>
>> Committers: please test, vote, and send your sigs!
>>
>
> I have tested the tar on Win32: All 6 combo's passed without errors.
Here's my signature for the windows .zip as well:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQBCyW7TU0gaaOxrUVYRAvDSAJ9rX/1yvE5utuWo/A3rMtUT2aCIeQCg1A+A
qs0pClpzcL5I3aBAWkHNers=
=kLhS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.1 tarballs are up for testing/voting
Posted by Erik Huelsmann <e....@gmx.net>.
> Ben Reser has posted 1.2.1 tarballs.
>
> Committers: please test, vote, and send your sigs!
I have tested the tar on Win32: All 6 combo's passed without errors.
My sig for the .zip:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBCx9Ari5O0Epaz9TkRAqIsAJ4o0k1OCRV1gVUTgy7qin4ZN3ttcQCfcalR
Df1gKMP6yI3gmoJFzEpDsS4=
=EPfw
-----END PGP SIGNATURE-----
bye,
Erik.
--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f�r Mail, Message, More +++
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.1 tarballs are up for testing/voting
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> Ben Reser has posted 1.2.1 tarballs.
> Hopefully we'll see a final 1.2.1 release in the next couple of days.
> Tarballs are up at http://fornix.brain.org/subversion/
>
> -rw-rw-r-- 1 svnrm svnrm 7226600 Jul 1 16:19 subversion-1.2.1.tar.bz2
> -rw-rw-r-- 1 svnrm svnrm 8847778 Jul 1 16:19 subversion-1.2.1.tar.gz
> -rw-rw-r-- 1 svnrm svnrm 11683706 Jul 1 16:23 subversion-1.2.1.zip
I tested over all six combinations of repos db and RA, on Debian
GNU/Linux, running approximately the latest 'sarge' release, with no
anchovies. Here are my signatures:
subversion-1.2.1.tar.bz2:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCxiGuvJ27E9sAokgRApHzAKDA58T+hn46FKuqIsSBHBL4XSsOPACdFdtq
0/HEG7Uu8Ad6PbQmdjLvYaQ=
=m4Av
-----END PGP SIGNATURE-----
subversion-1.2.1.tar.gz:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCxiGlvJ27E9sAokgRAo7PAKDm8o0dt+S6/QEBz3zcwbp2cIvuHQCfXlI0
+ibLIQPiv9FGRCTmB/jI+qI=
=er6N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2.1 tarballs are up for testing/voting
Posted by John Szakmeister <jo...@szakmeister.net>.
On Friday 01 July 2005 16:40, Ben Collins-Sussman wrote:
> Ben Reser has posted 1.2.1 tarballs.
>
> Committers: please test, vote, and send your sigs!
>
> Non-committers: please test anyway. :-)
>
> Hopefully we'll see a final 1.2.1 release in the next couple of days.
>
> Tarballs are up at http://fornix.brain.org/subversion/
>
>
> -rw-rw-r-- 1 svnrm svnrm 7226600 Jul 1 16:19 subversion-1.2.1.tar.bz2
> -rw-rw-r-- 1 svnrm svnrm 8847778 Jul 1 16:19 subversion-1.2.1.tar.gz
> -rw-rw-r-- 1 svnrm svnrm 11683706 Jul 1 16:23 subversion-1.2.1.zip
Tested in all 6 combinations of RA and fs on SuSE Linux 9.2. Here are my
signatures:
subversion-1.2.1.tar.gz:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCxv5dRUizqMDXDBIRAhUtAJ9YCQokk1XtqqLTqEY/hjXA5w3PMwCgmgzn
YLI3jHcjCYTnRVSjY+BzkdU=
=wkty
-----END PGP SIGNATURE-----
subversion-1.2.1.tar.bz2:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQBCxv4gRUizqMDXDBIRAjxgAJ0ccAr+/MAI/X+Bubjd7/X4Det01wCbBMVa
JaPReb152n96KOOiq6xGy0E=
=Euex
-----END PGP SIGNATURE-----
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org