You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@codematters.co.uk> on 2002/05/29 03:55:52 UTC
more fallout from rev 2024?
% svn st -u
_ * 2025 000000)
_ * 2025 (8¨¾6
M 2025 ./subversion/libsvn_wc/update_editor.c
M_ 2025 ./subversion/tests/clients/cmdline/basic_tests.py
_ * 2025 ./subversion/tests/libsvn_subr/time-test(`
Head revision: 2026
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> % svn st -u
> _ * 2025 000000)
> _ * 2025 (8¨¾6
> M 2025 ./subversion/libsvn_wc/update_editor.c
> M_ 2025 ./subversion/tests/clients/cmdline/basic_tests.py
> _ * 2025 ./subversion/tests/libsvn_subr/time-test(`
> Head revision: 2026
Very likely it *is* fallout, yes. I know that "make check" passes and
that I'm wasn't witnessing any problems in my daily use, but I'd be a
fool to claim there are no bugs in there :-).
I'll take a look, thanks for reporting and for the valgrind results.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Blair Zajac <bl...@orcaware.com> writes:
> > Maybe we should add valgrind to make check if configure finds it on
> > the system so we catch these earlier than waiting for a user to
> > stumble across a bug.
>
> What's involved in a valgrind run? Does it take a really long time,
> or is it just a special environment in which the usual tests would
> run?
First off, valgrind works on Linux ELF x86 executables. I don't know
if it works on other ELF x86 platforms. It simulates an x86 processor
and interprets the x86 code, allowing it to track every read/write to
memory, for both stack and heap.
Instead of invoking
% executable arguments
one uses
% valgrind executable arguments
and the valgrind report is printed on stderr. There are valgrind
options to print memory leak summaries, or to attach gdb when an error
is detected. Invoking valgrind on a libtool wrapper script isn't
useful, so one needs to use a static build or an installed shared
build.
Runtime increases are substantial (think orders of magnitude):
% time svn st ../svn/tools/
real 0m0.140s
user 0m0.110s
sys 0m0.030s
% time valgrind svn st ../svn/tools/
real 0m5.962s
user 0m5.790s
sys 0m0.170s
Memory usage also increases dramatically.
The really tricky bit is that lots of the valgrind checks are defeated
by the standard APR pools. Things like using uninitialised memory,
using free'd memory, etc., won't be detected if the APR pools reuse
memory rather than free'ing it. Building Subversion with
APR_POOL_DEBUG makes valgrind much more useful.
I had to patch the 20020511 valgrind snapshot to make it work with
Subversion (to support pread/pwrite). I sent the patch upstream and I
think it has been incorporated, but I haven't tried any of the later
snapshots. valgrind is under active development.
Running valgrind on the ELF binary test executables is quite
straightforward, I think I've done most of them manually over the past
couple of weeks. Lots of our tests involve Python invoking the svn
client. Getting these to run with valgrind would involve getting
Python to invoke valgrind svn instead of svn, that's probably quite
simple. However they would also need to handle the valgrind output and
separate it from the svn output, that's more complex. valgrind has a
--logfile-fd option that may help, but I've never used it. Finally
the valgrind output would need to be interpreted.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
sam th <sa...@uchicago.edu> writes:
> 1. Tinderbox is useful, independent of it's integration with CVS.
> Thus, Subversion could profitably use Tinderbox to check its own
> status.
>
> 2. Tinderbox is even more useful in conjunction with CVS (and esp. with
> the other Mozilla-derived tools such as Bonsai). In order for
> subversion to replace CVS, it will have to have this same integration.
>
> My suggestion was that performing this integration would make (1) more
> useful, and achieve (2).
Do you have time to take it on?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by sam th <sa...@uchicago.edu>.
On Thu, 2002-05-30 at 10:19, Karl Fogel wrote:
> > The other big advantage is that big projects aren't going to use svn
> > unless it can integrate with tinderbox, and associated tools. So doing
> > the work for svn is a good way to start on this.
>
> Hunh. Are you talking about
>
> Using tinderbox to check the status of Subversion itself
>
> or
>
> Integrating Subversion and Tinderbox so that projects in Subversion
> can more easily use Tinderbox to check their own status
Both.
1. Tinderbox is useful, independent of it's integration with CVS.
Thus, Subversion could profitably use Tinderbox to check its own
status.
2. Tinderbox is even more useful in conjunction with CVS (and esp. with
the other Mozilla-derived tools such as Bonsai). In order for
subversion to replace CVS, it will have to have this same integration.
My suggestion was that performing this integration would make (1) more
useful, and achieve (2).
--
sam th OpenPGP Key: CABD33FC
"Life is polynomial time." -- Laszlo Babai
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
> The other big advantage is that big projects aren't going to use svn
> unless it can integrate with tinderbox, and associated tools. So doing
> the work for svn is a good way to start on this.
Hunh. Are you talking about
Using tinderbox to check the status of Subversion itself
or
Integrating Subversion and Tinderbox so that projects in Subversion
can more easily use Tinderbox to check their own status
or both? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by sam th <sa...@uchicago.edu>.
On Wed, 2002-05-29 at 10:16, Karl Fogel wrote:
> Blair Zajac <bl...@orcaware.com> writes:
> > Has anybody thought about using Tinderbox
> >
> > http://www.mozilla.org/projects/tinderbox/
> >
> > to help subversion track breakage?
>
> Are you familiar with Tinderbox? (I.e., what specific advantages
> would we get? I don't know much about tbox.)
Tinderbox is a really cool tool, although it can be hard to set up.
The basic idea is that it continously runs the build (+ optional tests)
on a number of different platforms, so that you can see where the build
is broken, and where the tests are failing. Then you get a nice graphic
showing the builds that are succeding, failing, failing tests, etc. You
can also see who committed things that broke the builds, but that
requires integration with cvs, that would have to be reimplmented for
svn.
All in all, you get lots of nice info on the status of your code.
The other big advantage is that big projects aren't going to use svn
unless it can integrate with tinderbox, and associated tools. So doing
the work for svn is a good way to start on this.
--
sam th OpenPGP Key: CABD33FC
"Life is polynomial time." -- Laszlo Babai
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Blair Zajac <bl...@orcaware.com>.
Karl Fogel wrote:
> Blair Zajac <bl...@orcaware.com> writes:
> Are you familiar with Tinderbox? (I.e., what specific advantages
> would we get? I don't know much about tbox.)
I haven't used it yet but am installing it for our code base as it
looks pretty useful to test the code on a variety of different platforms
and see what broke and who broke it. It makes pages like this:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Ports
It looks like it could be tied into the svn-breakage mailing list
to create this stuff, but could be a decent amount of work.
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Blair Zajac <bl...@orcaware.com> writes:
> Maybe we should add valgrind to make check if configure finds it on
> the system so we catch these earlier than waiting for a user to
> stumble across a bug.
What's involved in a valgrind run? Does it take a really long time,
or is it just a special environment in which the usual tests would
run?
> Has anybody thought about using Tinderbox
>
> http://www.mozilla.org/projects/tinderbox/
>
> to help subversion track breakage?
Are you familiar with Tinderbox? (I.e., what specific advantages
would we get? I don't know much about tbox.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Blair Zajac <bl...@orcaware.com>.
Philip Martin wrote:
>
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > % svn st -u
> > _ * 2025 000000)
> > _ * 2025 (8¨¾6
> > M 2025 ./subversion/libsvn_wc/update_editor.c
> > M_ 2025 ./subversion/tests/clients/cmdline/basic_tests.py
> > _ * 2025 ./subversion/tests/libsvn_subr/time-test(`
> > Head revision: 2026
>
> valgrind is reporting the use of free'd memory for 'svn st -u':
Maybe we should add valgrind to make check if configure finds it on
the system so we catch these earlier than waiting for a user to
stumble across a bug.
Has anybody thought about using Tinderbox
http://www.mozilla.org/projects/tinderbox/
to help subversion track breakage?
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: more fallout from rev 2024?
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> % svn st -u
> _ * 2025 000000)
> _ * 2025 (8¨¾6
> M 2025 ./subversion/libsvn_wc/update_editor.c
> M_ 2025 ./subversion/tests/clients/cmdline/basic_tests.py
> _ * 2025 ./subversion/tests/libsvn_subr/time-test(`
> Head revision: 2026
valgrind is reporting the use of free'd memory for 'svn st -u':
==6920== Invalid read of size 1
==6920== at 0x4038F866: svn_path_compare_paths (in /usr/local/subversion/lib/libsvn_subr.so.0.0.0)
==6920== by 0x40390A79: svn_sort_compare_items_as_paths (../svn/subversion/libsvn_subr/sorts.c:74)
==6920== by 0x405D4323: (within /lib/libc-2.2.5.so)
==6920== by 0x405D4277: (within /lib/libc-2.2.5.so)
==6920== Address 0x4342CB00 is 0 bytes inside a block of size 21 free'd
==6920== at 0x40040B22: (within /usr/lib/valgrind/valgrind.so)
==6920== by 0x40463993: pool_clear_debug (apr_pools.c:1364)
==6920== by 0x40463A2E: apr_pool_destroy_debug (apr_pools.c:1398)
==6920== by 0x40365DA8: wrap_close_directory (../svn/subversion/libsvn_delta/default_editor.c:389)
(gdb) bt
#0 0x4005f49f in vgPlain_shutdown_logging ()
from /usr/lib/valgrind/valgrind.so
#1 0x00002360 in ?? ()
#2 0x4038f866 in svn_path_compare_paths (path1=0xbffff70c, path2=0xbffff6fc)
at ../svn/subversion/libsvn_subr/path.c:489
#3 0x40390a79 in svn_sort_compare_items_as_paths (a=0x43478b48, b=0x43478b54)
at ../svn/subversion/libsvn_subr/sorts.c:74
#4 0x405d4323 in bsearch () from /lib/libc.so.6
#5 0x405d4277 in bsearch () from /lib/libc.so.6
#6 0x405d43fe in qsort () from /lib/libc.so.6
#7 0x40390bc4 in apr_hash_sorted_keys (ht=0x43398c98,
comparison_func=0x8049e10 <svn_sort_compare_items_as_paths>,
pool=0x4339647c) at ../svn/subversion/libsvn_subr/sorts.c:123
#8 0x0804f3fa in svn_cl__print_status_list (statushash=0x43398c98,
youngest=6, detailed=1, show_last_committed=0, skip_unrecognized=0,
pool=0x4339647c) at ../svn/subversion/clients/cmdline/status.c:236
#9 0x0804f093 in svn_cl__status (os=0x43396ee4, opt_state=0xbffff9d0,
pool=0x4339647c) at ../svn/subversion/clients/cmdline/status-cmd.c:74
#10 0x0804dadf in main (argc=4, argv=0xbffffab4)
at ../svn/subversion/clients/cmdline/main.c:1121
(gdb) up 2
#2 0x4038f866 in svn_path_compare_paths (path1=0xbffff70c, path2=0xbffff6fc)
at ../svn/subversion/libsvn_subr/path.c:489
489 while (i < min_len && path1->data[i] == path2->data[i])
(gdb) p (char*)0x4342CB00
$11 = 0x4342cb00 "/home/pm/wc/branches"
(gdb) p path1[0].data
$12 = 0x4342cb00 "/home/pm/wc/branches"
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org