You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2002/06/19 23:07:46 UTC
Re: svn commit: rev 2288 - trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta
Folks, I need a bit of help here. I've come to the point where I can't
trip up the delta combiner any more, and I'd like to have independent
confirmation that it is, indeed, untrippable.
Used to be that if I ran
random-test -n100000 2
I'd sooner or later get a combination that failed. Now this test runs
out of FILE* handles on Windows (must be a leak in the C runtime, I
can't imagine how this could happen otherwise), but doesn't fail in the
combiner.
So, I'd like to ask people to check out HEAD, compile and run this test
on as many machines as possible, and post the output. 100000 repetitions
would take about 5 hours on my box (450MHz PIII).
In the meantime, I'm letting the test run overnight in a loop with -n1000.
Thanks,
Brane
brane@tigris.org wrote:
>Author: brane
>Date: 2002-06-19 22:07 GMT
>New Revision: 2288
>
>Modified:
> trunk/subversion/libsvn_delta/compose_delta.c
> trunk/subversion/tests/libsvn_delta/random-test.c
>Log:
>Ongoing work on the delta combiner (issue #531).
>
>* compose_delta (copy_source_ops): Accept new parameter, target_offset,
>and use it when generating an overlapping target copy.
>Correct offset and range calculation for transposing the repeating pattern
>in an overlapping copy.
>
>* random-test.c (do_random_combine_test): Rename from random_combine_test,
>and add a mechanism to report the last seed used.
>(random_combine_test): New. Wrapper for do_random_combine_test.
>
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2288 - trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>I ran: random-test -n100000 -l200000 2 (I wanted to test bigger files;
>definitely larger than a single window)
>
That's not a problem -- random-test generates files that are a random
multiple of the chunk size, and the default chunk size is the window
size, so you'll definitely get files that are larger than a single window.
>It ran for maybe four to six hours. Not entirely sure. It didn't complete,
>but it definitely didn't throw any errors.
>
>
Great!
Everybody, thanks for testing this. I think I can safely say that the
combiner works. I'll start integrating it into the filesystem now.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2288 - trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jun 20, 2002 at 01:07:46AM +0200, Branko Cibej wrote:
> Folks, I need a bit of help here. I've come to the point where I can't
> trip up the delta combiner any more, and I'd like to have independent
> confirmation that it is, indeed, untrippable.
>
> Used to be that if I ran
>
> random-test -n100000 2
>...
> So, I'd like to ask people to check out HEAD, compile and run this test
> on as many machines as possible, and post the output. 100000 repetitions
> would take about 5 hours on my box (450MHz PIII).
I ran: random-test -n100000 -l200000 2 (I wanted to test bigger files;
definitely larger than a single window)
It ran for maybe four to six hours. Not entirely sure. It didn't complete,
but it definitely didn't throw any errors.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2288 - trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta
Posted by Ben Collins-Sussman <su...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> >>So, I'd like to ask people to check out HEAD, compile and run this
> >>test on as many machines as possible, and post the output. 100000
> >>repetitions would take about 5 hours on my box (450MHz PIII).
Ran it overnight on my development box:
SEED: random combine delta test, seed = 2700618839
SEED: Last seen = 760053867
PASS: random-test 2: random combine delta test, seed = 2700618839
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2288 - trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>So, I'd like to ask people to check out HEAD, compile and run this
>>test on as many machines as possible, and post the output. 100000
>>repetitions would take about 5 hours on my box (450MHz PIII).
>>
>>
>
>It runs successfully on my x86 Linux box under valgrind, compiled with
>APR_POOL_DEBUG=1 and without optimisation (100000 iterations would
>take over a month :-)
>
Really? -n1000 takes just about 3 minutes on my box, so 5 hours for
-n100000 should be about right.
Oh, I see, you're running it with valgrind! That would slow down the
test quite a bit, I guess.
Anyway, thanks!
>
>$ valgrind subversion/tests/libsvn_delta/.libs/lt-random-test -n10 2
>==30848== valgrind-1.0pre1, a memory error detector for x86 GNU/Linux.
>==30848== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
>==30848== Estimated CPU clock rate is 451 MHz
>==30848== For more details, rerun with: -v
>==30848==
>SEED: random combine delta test, seed = 350685093
>SEED: Last seen = 1846555367
>PASS: lt-random-test 2: random combine delta test, seed = 350685093
>==30848== pthread_mutex_unlock: mutex is not locked
>==30848== at 0x403AB4BF: (within /usr/lib/valgrind/libpthread.so)
>==30848== by 0x40339043: thread_mutex_cleanup (thread_mutex.c:67)
>==30848== by 0x4033BCD2: run_cleanups (apr_pools.c:1940)
>==30848== by 0x4033B3B9: pool_clear_debug (apr_pools.c:1361)
>==30848==
>==30848== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 60 from 1)
>==30848== malloc/free: in use at exit: 0 bytes in 0 blocks.
>==30848== malloc/free: 2846 allocs, 2846 frees, 18103340 bytes allocated.
>==30848== For a detailed leak analysis, rerun with: --leak-check=yes
>==30848== For counts of detected errors, rerun with: -v
>
>The pthread errors are coming from APR, thread_mutex_cleanup calls
>pthread_mutex_unlock when destroying a mutex. I suppose the author
>wanted to ensure it was unlocked, but it's strictly undefined
>behaviour.
>
>
Could you raise this issue on the APR list?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 2288 - trunk/subversion/tests/libsvn_delta trunk/subversion/libsvn_delta
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> So, I'd like to ask people to check out HEAD, compile and run this
> test on as many machines as possible, and post the output. 100000
> repetitions would take about 5 hours on my box (450MHz PIII).
It runs successfully on my x86 Linux box under valgrind, compiled with
APR_POOL_DEBUG=1 and without optimisation (100000 iterations would
take over a month :-)
$ valgrind subversion/tests/libsvn_delta/.libs/lt-random-test -n10 2
==30848== valgrind-1.0pre1, a memory error detector for x86 GNU/Linux.
==30848== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==30848== Estimated CPU clock rate is 451 MHz
==30848== For more details, rerun with: -v
==30848==
SEED: random combine delta test, seed = 350685093
SEED: Last seen = 1846555367
PASS: lt-random-test 2: random combine delta test, seed = 350685093
==30848== pthread_mutex_unlock: mutex is not locked
==30848== at 0x403AB4BF: (within /usr/lib/valgrind/libpthread.so)
==30848== by 0x40339043: thread_mutex_cleanup (thread_mutex.c:67)
==30848== by 0x4033BCD2: run_cleanups (apr_pools.c:1940)
==30848== by 0x4033B3B9: pool_clear_debug (apr_pools.c:1361)
==30848==
==30848== ERROR SUMMARY: 5 errors from 1 contexts (suppressed: 60 from 1)
==30848== malloc/free: in use at exit: 0 bytes in 0 blocks.
==30848== malloc/free: 2846 allocs, 2846 frees, 18103340 bytes allocated.
==30848== For a detailed leak analysis, rerun with: --leak-check=yes
==30848== For counts of detected errors, rerun with: -v
The pthread errors are coming from APR, thread_mutex_cleanup calls
pthread_mutex_unlock when destroying a mutex. I suppose the author
wanted to ensure it was unlocked, but it's strictly undefined
behaviour.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org