You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2009/07/17 08:27:03 UTC
MAC OSX stack trace, please, for commit-tests.py 59
The MAC OSX buildbot is failing because of a seg-fault that occurs in
merge_tests.py 59. (See for example this recent failure email
<http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912> and follow the link to "Full details".)
Can a MAC user post a stack trace (including parameter values) of this
failure? It might help one of us to debug it. I will try if I can see a
stack trace.
Here are a few lines from the test log, where it fails, but I can't
learn much from them:
[[[
--- Merging r6 into
'svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H':
U svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/omega
CMD: svn proplist --verbose svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/chi svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/psi svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/omega svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H --config-dir /Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
<TIME = 0.140825>
Properties on 'svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H':
svn:mergeinfo
/A/D/H:6
CMD: svn status -v -u -q svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H --config-dir /Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
<TIME = 0.130362>
* 2 2 jrandom svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/psi
2 2 jrandom svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/chi
M 2 2 jrandom svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/omega
M * 2 2 jrandom svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H
Status against revision: 7
CMD: svn up svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H --config-dir /Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
CMD: /Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/svn/svn up svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H --config-dir /Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom terminated by signal 11
U svn-test-work/working_copies/merge_tests-59.other/A_COPY/D/H/psi
EXCEPTION: SVNProcessTerminatedBySignal
Traceback (most recent call last):
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/main.py", line 1149, in run
rc = self.pred.run(sandbox)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/testcase.py", line 200, in run
return self._delegate.run(sandbox)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/testcase.py", line 129, in run
return self.func(sandbox)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/merge_tests.py", line 6903, in merge_to_out_of_date_target
check_props=1)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/actions.py", line 682, in run_and_verify_update
*args)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/main.py", line 587, in run_svn
*(_with_auth(_with_config_dir(varargs))))
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/main.py", line 365, in run_command
None, *varargs)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/main.py", line 506, in run_command_stdin
*varargs)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/main.py", line 482, in spawn_process
stdout_lines, stderr_lines, exit_code = wait_on_pipe(kid, binary_mode)
File "/Users/lgo/slavedir/osx10.4-gcc4.0.1-ia32/build/subversion/tests/cmdline/svntest/main.py", line 458, in wait_on_pipe
raise SVNProcessTerminatedBySignal
SVNProcessTerminatedBySignal
FAIL: merge_tests.py 59: merge to ood path can lead to inaccurate mergeinfo
]]]
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2371987
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Julian Foad <ju...@btopenworld.com>.
Hyrum K. Wright wrote:
> On Jul 17, 2009, at 9:47 AM, Julian Foad wrote:
> > The exact same construct appears a few lines further down as well,
> > inside the children loop, so doesn't the same change need to be made
> > there?
>
> I don't think so. In the children loop, we continue if we find an
> error. In the above, we aren't in a loop, and so have no ability to
> use the continue statement.
Oh yes... it's not the exact same construct.
Anyway, your fix makes the valgrind error go away on both merge_tests 56
and 59 for me, so that's good. Let's see if it fixes the Mac buildbot.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372089
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Jul 17, 2009, at 9:47 AM, Julian Foad wrote:
> Hyrum K. Wright wrote:
>> I *think* I fixed this in r38436, but I have no way of testing
>> locally, so I'll have to sit back and see if the buildbots go green.
>> (Or somebody else can run the test through valgrind and see if this
>> fixes the previously presented error.)
>
> I see... Looks likely. Quoting your change...
> [[[
> Index: subversion/libsvn_wc/entries.c
> ===================================================================
> --- subversion/libsvn_wc/entries.c (revision 38435)
> +++ subversion/libsvn_wc/entries.c (revision 38436)
> @@ -2353,20 +2353,20 @@ entries_write_body(svn_wc__db_t *db,
> scratch_pool, scratch_pool);
> if (err && err->apr_err == SVN_ERR_WC_PATH_NOT_FOUND)
> {
> /* We could be looking at a newly added node, without a BASE
> node,
> and hence no dav cache, so just ignore the error. */
> svn_error_clear(err);
> }
> else if (err)
> return err;
> -
> - apr_hash_set(dav_cache, local_abspath, APR_HASH_KEY_STRING,
> child_cache);
> + else
> + apr_hash_set(dav_cache, local_abspath, APR_HASH_KEY_STRING,
> child_cache);
>
> SVN_ERR(svn_wc__db_base_get_children(&children, db, local_abspath,
> scratch_pool, scratch_pool));
>
> for (i = 0; i < children->nelts; i++)
> {
> ]]]
>
> The exact same construct appears a few lines further down as well,
> inside the children loop, so doesn't the same change need to be made
> there?
I don't think so. In the children loop, we continue if we find an
error. In the above, we aren't in a loop, and so have no ability to
use the continue statement.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372086
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Julian Foad <ju...@btopenworld.com>.
Hyrum K. Wright wrote:
> I *think* I fixed this in r38436, but I have no way of testing
> locally, so I'll have to sit back and see if the buildbots go green.
> (Or somebody else can run the test through valgrind and see if this
> fixes the previously presented error.)
I see... Looks likely. Quoting your change...
[[[
Index: subversion/libsvn_wc/entries.c
===================================================================
--- subversion/libsvn_wc/entries.c (revision 38435)
+++ subversion/libsvn_wc/entries.c (revision 38436)
@@ -2353,20 +2353,20 @@ entries_write_body(svn_wc__db_t *db,
scratch_pool, scratch_pool);
if (err && err->apr_err == SVN_ERR_WC_PATH_NOT_FOUND)
{
/* We could be looking at a newly added node, without a BASE node,
and hence no dav cache, so just ignore the error. */
svn_error_clear(err);
}
else if (err)
return err;
-
- apr_hash_set(dav_cache, local_abspath, APR_HASH_KEY_STRING, child_cache);
+ else
+ apr_hash_set(dav_cache, local_abspath, APR_HASH_KEY_STRING, child_cache);
SVN_ERR(svn_wc__db_base_get_children(&children, db, local_abspath,
scratch_pool, scratch_pool));
for (i = 0; i < children->nelts; i++)
{
]]]
The exact same construct appears a few lines further down as well,
inside the children loop, so doesn't the same change need to be made
there?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372083
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Jul 17, 2009, at 8:36 AM, Hyrum K. Wright wrote:
> On Jul 17, 2009, at 3:27 AM, Julian Foad wrote:
>
>> The MAC OSX buildbot is failing because of a seg-fault that occurs in
>> merge_tests.py 59. (See for example this recent failure email
>> <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912
>>> and follow the link to "Full details".)
>>
>> Can a MAC user post a stack trace (including parameter values) of
>> this
>> failure? It might help one of us to debug it. I will try if I can
>> see a
>> stack trace.
>
> I can't reproduce this locally, but that seems to say to me "memory
> bug!" Philip's valgrind trace posted elsethread appears to confirm
> this.
I *think* I fixed this in r38436, but I have no way of testing
locally, so I'll have to sit back and see if the buildbots go green.
(Or somebody else can run the test through valgrind and see if this
fixes the previously presented error.)
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372079
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jul 17, 2009 at 08:36:34AM -0500, Hyrum K. Wright wrote:
> On Jul 17, 2009, at 3:27 AM, Julian Foad wrote:
>
> > The MAC OSX buildbot is failing because of a seg-fault that occurs in
> > merge_tests.py 59. (See for example this recent failure email
> > <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912
> > > and follow the link to "Full details".)
> >
> > Can a MAC user post a stack trace (including parameter values) of this
> > failure? It might help one of us to debug it. I will try if I can
> > see a
> > stack trace.
>
> I can't reproduce this locally, but that seems to say to me "memory
> bug!" Philip's valgrind trace posted elsethread appears to confirm
> this.
Yeah and it might also explain the trace below for test 56 I showed
Paul the other day. So far we've been unable to figure out the problem.
Note the bogus input being passed to svn_mergeinfo_parse().
Stefan
stsp@jack [~/svn/svn-trunk/subversion/tests/cmdline] $ gdb --args svn merge -r2:3 file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B svn-test-work/working_copies/merge_tests-56.other/A/C --dry-run --config-dir /home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) br subversion/libsvn_subr/mergeinfo.c:91
No source file named subversion/libsvn_subr/mergeinfo.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (subversion/libsvn_subr/mergeinfo.c:91) pending.
(gdb) run
Starting program: /home/stsp/svn/prefix/svn-trunk/bin/svn merge -r2:3 file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B svn-test-work/working_copies/merge_tests-56.other/A/C --dry-run --config-dir /home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/local_tmp/config --password rayjandom --no-auth-cache --username jrandom
[Thread debugging using libthread_db enabled]
[New Thread 0xb78a7a10 (LWP 25984)]
[New Thread 0xb76f5b90 (LWP 25987)]
[Thread 0xb76f5b90 (LWP 25987) exited]
[Switching to Thread 0xb78a7a10 (LWP 25984)]
Breakpoint 1, parse_pathname (input=0xbffaa164, end=0x91ae754 "",
pathname=0xbffaa0b8, pool=0x90fd460)
at subversion/libsvn_subr/mergeinfo.c:91
91 return svn_error_create(SVN_ERR_MERGEINFO_PARSE_ERROR, NULL,
(gdb) bt
#0 parse_pathname (input=0xbffaa164, end=0x91ae754 "", pathname=0xbffaa0b8,
pool=0x90fd460) at subversion/libsvn_subr/mergeinfo.c:91
#1 0xb7de864f in parse_revision_line (input=0xbffaa164, end=0x91ae754 "",
hash=0x91ae7c8, pool=0x90fd460) at subversion/libsvn_subr/mergeinfo.c:498
#2 0xb7de8ae0 in parse_top (input=0xbffaa164, end=0x91ae754 "",
hash=0x91ae7c8, pool=0x90fd460) at subversion/libsvn_subr/mergeinfo.c:578
#3 0xb7de8b89 in svn_mergeinfo_parse (mergeinfo=0xbffaa1e4,
input=0x91ae748 "�2\227\t�D�\t�$�\t", pool=0x90fd460)
at subversion/libsvn_subr/mergeinfo.c:591
#4 0xb7f70256 in svn_client__parse_mergeinfo (mergeinfo=0xbffaa1e4,
entry=0x90d2288,
wcpath=0x90fd8e0 "svn-test-work/working_copies/merge_tests-56.other/A/C",
pristine=0, adm_access=0x90d1ee0, ctx=0x90b6bb0, pool=0x90fd460)
at subversion/libsvn_client/mergeinfo.c:89
#5 0xb7f70699 in svn_client__get_wc_mergeinfo (mergeinfo=0x90fd8cc,
inherited=0xbffaa30c, pristine=0, inherit=svn_mergeinfo_inherited,
entry=0x90d2288,
wcpath=0x90fd8e0 "svn-test-work/working_copies/merge_tests-56.other/A/C",
limit_path=0x0, walked_path=0x0, adm_access=0x90d1ee0, ctx=0x90b6bb0,
pool=0x90fd460) at subversion/libsvn_client/mergeinfo.c:209
#6 0xb7f70d92 in svn_client__get_wc_or_repos_mergeinfo (
target_mergeinfo=0x90fd8cc, entry=0x90d2288, indirect=0xbffaa30c,
repos_only=0, inherit=svn_mergeinfo_inherited, ra_session=0x9160c78,
target_wcpath=0x90fd8e0 "svn-test-work/working_copies/merge_tests-56.other/A/C", adm_access=0x90d1ee0, ctx=0x90b6bb0, pool=0x90fd460)
at subversion/libsvn_client/mergeinfo.c:389
#7 0xb7f62867 in get_full_mergeinfo (recorded_mergeinfo=0x90fd8cc,
implicit_mergeinfo=0x90fd8d0, entry=0x90d2288, indirect=0x90fd8d4,
inherit=svn_mergeinfo_inherited, ra_session=0x9160c78,
target_wcpath=0x90fd8e0 "svn-test-work/working_copies/merge_tests-56.other/A/C", start=3, end=2, adm_access=0x90d1ee0, ctx=0x90b6bb0, pool=0x90fd460)
at subversion/libsvn_client/merge.c:2853
#8 0xb7f64415 in populate_remaining_ranges (
children_with_mergeinfo=0x90fd590,
source_root_url=0x90fd5b0 "file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56",
url1=0x90d3ca0 "file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B", revision1=2,
url2=0x90d3d20 "file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B", revision2=3, honor_mergeinfo=1,
ra_session=0x9160c78, parent_merge_src_canon_path=0x90fd638 "/A/B",
adm_access=0x90d1ee0, merge_b=0xbffaa5b4, pool=0x90fd460)
at subversion/libsvn_client/merge.c:3772
#9 0xb7f6b037 in do_directory_merge (
url1=0x90d3ca0 "file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B", revision1=2,
url2=0x90d3d20 "file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B", revision2=3,
target_entry=0x90d2288, adm_access=0x90d1ee0, depth=svn_depth_infinity,
notify_b=0xbffaa584, merge_b=0xbffaa5b4, pool=0x90fd460)
at subversion/libsvn_client/merge.c:6987
#10 0xb7f6bdb8 in do_merge (merge_sources=0x90d3af8,
target=0x90c17a0 "svn-test-work/working_copies/merge_tests-56.other/A/C",
target_entry=0x90d2288, adm_access=0x90d1ee0, sources_ancestral=1,
sources_related=1, same_repos=1, ignore_ancestry=0, force=0, dry_run=1,
record_only=0, reintegrate_merge=0, depth=svn_depth_infinity,
merge_options=0x0, use_sleep=0xbffaa6d4, ctx=0x90b6bb0, pool=0x90b59b0)
at subversion/libsvn_client/merge.c:7431
#11 0xb7f70034 in svn_client_merge_peg3 (
source=0x90c1580 "file:///home/stsp/svn/svn-trunk/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-56/A/B", ranges_to_merge=0x90b5b38,
peg_revision=0xbffaa7b8,
target_wcpath=0x90c17a0 "svn-test-work/working_copies/merge_tests-56.other/A/C", depth=svn_depth_unknown, ignore_ancestry=0, force=0, record_only=0,
dry_run=1, merge_options=0x0, ctx=0x90b6bb0, pool=0x90b59b0)
at subversion/libsvn_client/merge.c:8819
#12 0x0805b852 in svn_cl__merge (os=0x90b5b58, baton=0xbffaa934,
pool=0x90b59b0) at subversion/svn/merge-cmd.c:313
#13 0x0805acd3 in main (argc=13, argv=0xbffaab64) at subversion/svn/main.c:2115
(gdb)
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Jul 17, 2009, at 3:27 AM, Julian Foad wrote:
> The MAC OSX buildbot is failing because of a seg-fault that occurs in
> merge_tests.py 59. (See for example this recent failure email
> <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912
> > and follow the link to "Full details".)
>
> Can a MAC user post a stack trace (including parameter values) of this
> failure? It might help one of us to debug it. I will try if I can
> see a
> stack trace.
I can't reproduce this locally, but that seems to say to me "memory
bug!" Philip's valgrind trace posted elsethread appears to confirm
this.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372061
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Fri, Jul 17, 2009 at 10:27 AM, Julian Foad<ju...@btopenworld.com> wrote:
> The MAC OSX buildbot is failing because of a seg-fault that occurs in
> merge_tests.py 59. (See for example this recent failure email
> <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912> and follow the link to "Full details".)
>
> Can a MAC user post a stack trace (including parameter values) of this
> failure? It might help one of us to debug it. I will try if I can see a
> stack trace.
I can't get gdb to correctly print a stacktrace of the core files, so
this crash report will have to do.
Note that the line numbers aren't correct.
If anyone can tell me how to get a decent stacktrace from the core
files when all the libraries are dynamically built I can get a better
report.
Lieven
-------------------------
0 libsvn_subr-1.0.dylib 0x00601a5e svn_dirent_join + 66
(dirent_uri.c:746)
1 libsvn_wc-1.0.dylib 0x0033a6e2 get_entry_url + 76
(update_editor.c:430)
2 libsvn_wc-1.0.dylib 0x0033aae1 make_dir_baton + 473
(update_editor.c:572)
3 libsvn_wc-1.0.dylib 0x0033bca6 open_root + 74 (update_editor.c:1242)
4 libsvn_delta-1.0.dylib 0x005d1be4 open_root + 112 (cancel.c:67)
5 libsvn_ra_neon-1.0.dylib 0x00526cec start_element + 1659 (fetch.c:1490)
6 libsvn_ra_neon-1.0.dylib 0x00538483 wrapper_startelm_cb + 91
(util.c:1028)
7 libsvn_ra_neon-1.0.dylib 0x0053dd0d start_element + 656 (ne_xml.c:329)
8 libxml2.2.dylib 0x91c11fdf xmlParseStartTag + 1563
9 libxml2.2.dylib 0x91bf34ec xmlParseChunk + 1925
10 libsvn_ra_neon-1.0.dylib 0x0053dfca ne_xml_parse + 169 (ne_xml.c:542)
11 libsvn_ra_neon-1.0.dylib 0x00538962 cancellation_callback + 199
(util.c:1149)
12 libsvn_ra_neon-1.0.dylib 0x00539ffd ne_read_response_block +
192 (ne_request.c:882)
13 libsvn_ra_neon-1.0.dylib 0x0053a3f3 ne_discard_response + 34
(ne_request.c:1419)
14 libsvn_ra_neon-1.0.dylib 0x0053b8f9 ne_request_dispatch + 46
(ne_request.c:1430)
15 libsvn_ra_neon-1.0.dylib 0x005391be
svn_ra_neon__request_dispatch + 343 (util.c:1450)
16 libsvn_ra_neon-1.0.dylib 0x00538b78 parsed_request + 467 (util.c:1229)
17 libsvn_ra_neon-1.0.dylib 0x00538d85 svn_ra_neon__parsed_request
+ 150 (util.c:1292)
18 libsvn_ra_neon-1.0.dylib 0x005297be reporter_finish_report +
490 (fetch.c:2401)
19 libsvn_wc-1.0.dylib 0x0030634c svn_wc_crawl_revisions4 +
1593 (adm_crawler.c:746)
20 libsvn_client-1.0.dylib 0x0023f4fd svn_client__update_internal
+ 2392 (update.c:263)
21 libsvn_client-1.0.dylib 0x0020adb0
svn_client__checkout_internal + 1506 (checkout.c:169)
22 libsvn_client-1.0.dylib 0x0020b0be svn_client_checkout3 + 96
(checkout.c:250)
23 svn 0x000044f2 svn_cl__checkout + 1003
(checkout-cmd.c:160)
24 svn 0x0000ee63 main + 11516 (main.c:2123)
-----------------------------------
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372325
Re: Running tests with Valgrind
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> On many or all repository-contacting executions of "svn" now, I get one
> Valgrind warning:
> [[[
> $ svn st -u notes/
> ==17537== Syscall param epoll_ctl(event) points to uninitialised byte(s)
> ==17537== at 0x47794EE: epoll_ctl (in /lib/libc-2.4.so)
> I don't know if that's a Serf issue or if it has been fixed. I'm using
> Serf 0.3.0.
It's probably a valgrind false-alarm (valgrind interprets the syscall
data to predict errors and doesn't always get it right).
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372137
Running tests with Valgrind [was: MAC OSX stack trace, please, for
commit-tests.py 59]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Philip Martin <ph...@codematters.co.uk> writes:
> > Stefan Sperling <st...@elego.de> writes:
> >> can you run the same for merge_test 56 (or show me how you run svn
> >> tests in valgrind)?
> >
> > The way I do it is to manually edit the subversion/svn/svn libtool
> > script after the build:
> >
> > - exec "$progdir/$program" ${1+"$@"}
> > + exec valgrind -q "$progdir/$program" ${1+"$@"}
> >
> > Then you run the regression tests as normal.
Thanks, Philip! That was really easy and will be very helpful.
> You probably need to enable apr's pool debugging to get the most out
> of valgrind. Configure Subversion with CFLAGS=-DAPR_POOL_DEBUG, maybe
Done that.
> build apr and apr-util with --enable-pool-debug as well.
Haven't done that. It looks like Valgrind is being useful without it.
On many or all repository-contacting executions of "svn" now, I get one
Valgrind warning:
[[[
$ svn st -u notes/
==17537== Syscall param epoll_ctl(event) points to uninitialised byte(s)
==17537== at 0x47794EE: epoll_ctl (in /lib/libc-2.4.so)
==17537== by 0x4276411: pollset_add (in /home/julianfoad/lib/libserf-0.so.0.0.0)
==17537== by 0x42752CA: update_pollset (in /home/julianfoad/lib/libserf-0.so.0.0.0)
==17537== by 0x42763AB: check_dirty_pollsets (in /home/julianfoad/lib/libserf-0.so.0.0.0)
==17537== by 0x42765EA: serf_context_prerun (in /home/julianfoad/lib/libserf-0.so.0.0.0)
==17537== by 0x42766B7: serf_context_run (in /home/julianfoad/lib/libserf-0.so.0.0.0)
==17537== by 0x4263041: svn_ra_serf__context_run_wait (util.c:545)
==17537== by 0x4254B28: svn_ra_serf__exchange_capabilities (options.c:476)
==17537== by 0x425A502: svn_ra_serf__open (serf.c:447)
==17537== by 0x4115098: svn_ra_open3 (ra_loader.c:485)
==17537== by 0x4079AFE: svn_client__open_ra_session_internal (ra.c:336)
==17537== by 0x4080BA2: svn_client_status5 (status.c:311)
==17537== Address 0xbeb0c268 is on thread 1's stack
]]]
I don't know if that's a Serf issue or if it has been fixed. I'm using
Serf 0.3.0.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372074
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> Stefan Sperling <st...@elego.de> writes:
>
>> can you run the same for merge_test 56 (or show me how you run svn
>> tests in valgrind)? I suspect that test may have similar problems.
>
> The way I do it is to manually edit the subversion/svn/svn libtool
> script after the build:
>
> --- svn.orig 2009-07-17 12:10:25.000000000 +0100
> +++ svn 2009-07-17 10:42:44.000000000 +0100
> @@ -133,7 +133,7 @@
> if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
> # Run the actual program with our arguments.
>
> - exec "$progdir/$program" ${1+"$@"}
> + exec valgrind -q "$progdir/$program" ${1+"$@"}
>
> $ECHO "$0: cannot exec $program $*" 1>&2
> exit 1
>
> Then you run the regression tests as normal.
You probably need to enable apr's pool debugging to get the most out
of valgrind. Configure Subversion with CFLAGS=-DAPR_POOL_DEBUG, maybe
build apr and apr-util with --enable-pool-debug as well.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372037
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Philip Martin <ph...@codematters.co.uk>.
Stefan Sperling <st...@elego.de> writes:
> can you run the same for merge_test 56 (or show me how you run svn
> tests in valgrind)? I suspect that test may have similar problems.
The way I do it is to manually edit the subversion/svn/svn libtool
script after the build:
--- svn.orig 2009-07-17 12:10:25.000000000 +0100
+++ svn 2009-07-17 10:42:44.000000000 +0100
@@ -133,7 +133,7 @@
if test "$libtool_execute_magic" != "%%%MAGIC variable%%%"; then
# Run the actual program with our arguments.
- exec "$progdir/$program" ${1+"$@"}
+ exec valgrind -q "$progdir/$program" ${1+"$@"}
$ECHO "$0: cannot exec $program $*" 1>&2
exit 1
Then you run the regression tests as normal.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372021
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Philip Martin <ph...@codematters.co.uk>.
Stefan Sperling <st...@elego.de> writes:
> can you run the same for merge_test 56 (or show me how you run svn
> tests in valgrind)? I suspect that test may have similar problems.
$ ../../../../src/subversion/tests/cmdline/merge_tests.py 56
==3190== Conditional jump or move depends on uninitialised value(s)
==3190== at 0x30210143EF: find_entry (in /usr/lib/libapr-1.so.0.2.12)
==3190== by 0x30210146D5: apr_hash_set (in /usr/lib/libapr-1.so.0.2.12)
==3190== by 0x4EB13B8: entries_write_body (entries.c:2363)
==3190== by 0x4EB1AF2: entries_write (entries.c:2469)
==3190== by 0x4EB313E: svn_wc__tweak_entry (entries.c:3150)
==3190== by 0x4E92BD6: tweak_entries (adm_ops.c:115)
==3190== by 0x4E9347A: svn_wc__do_update_cleanup (adm_ops.c:293)
==3190== by 0x4E96D17: svn_wc_add3 (adm_ops.c:1618)
==3190== by 0x4C47709: merge_dir_added (merge.c:1949)
==3190== by 0x4C68251: add_directory (repos_diff.c:917)
==3190== by 0x74B0EEA: add_directory (cancel.c:115)
==3190== by 0x74B0EEA: add_directory (cancel.c:115)
==3190==
==3190== Conditional jump or move depends on uninitialised value(s)
==3190== at 0x30210146EB: apr_hash_set (in /usr/lib/libapr-1.so.0.2.12)
==3190== by 0x4EB13B8: entries_write_body (entries.c:2363)
==3190== by 0x4EB1AF2: entries_write (entries.c:2469)
==3190== by 0x4EB313E: svn_wc__tweak_entry (entries.c:3150)
==3190== by 0x4E92BD6: tweak_entries (adm_ops.c:115)
==3190== by 0x4E9347A: svn_wc__do_update_cleanup (adm_ops.c:293)
==3190== by 0x4E96D17: svn_wc_add3 (adm_ops.c:1618)
==3190== by 0x4C47709: merge_dir_added (merge.c:1949)
==3190== by 0x4C68251: add_directory (repos_diff.c:917)
==3190== by 0x74B0EEA: add_directory (cancel.c:115)
==3190== by 0x74B0EEA: add_directory (cancel.c:115)
==3190== by 0x574F7A1: update_entry (reporter.c:845)
==3190==
==3190== Conditional jump or move depends on uninitialised value(s)
==3190== at 0x30210146EB: apr_hash_set (in /usr/lib/libapr-1.so.0.2.12)
==3190== by 0x4EB13B8: entries_write_body (entries.c:2363)
==3190== by 0x4EB1AF2: entries_write (entries.c:2469)
==3190== by 0x4EB2A4D: svn_wc__entry_modify (entries.c:2979)
==3190== by 0x4E94D05: mark_tree (adm_ops.c:956)
==3190== by 0x4E96D9D: svn_wc_add3 (adm_ops.c:1626)
==3190== by 0x4C47709: merge_dir_added (merge.c:1949)
==3190== by 0x4C68251: add_directory (repos_diff.c:917)
==3190== by 0x74B0EEA: add_directory (cancel.c:115)
==3190== by 0x74B0EEA: add_directory (cancel.c:115)
==3190== by 0x574F7A1: update_entry (reporter.c:845)
==3190== by 0x575066F: delta_dirs (reporter.c:1126)
Traceback (most recent call last):
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 1149, in run
rc = self.pred.run(sandbox)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/testcase.py", line 200, in run
return self._delegate.run(sandbox)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/testcase.py", line 129, in run
return self.func(sandbox)
File "../../../../src/subversion/tests/cmdline/merge_tests.py", line 6618, in update_loses_mergeinfo
check_props=1)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/actions.py", line 820, in run_and_verify_merge
b_baton, check_props, dry_run)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/actions.py", line 888, in run_and_verify_merge2
exit_code, out, err = main.run_svn(error_re_string, *merge_command)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 587, in run_svn
*(_with_auth(_with_config_dir(varargs))))
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 365, in run_command
None, *varargs)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 520, in run_command_stdin
raise Failure
Failure
FAIL: merge_tests.py 56: update does not merge mergeinfo
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372060
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jul 17, 2009 at 10:44:32AM +0100, Philip Martin wrote:
> Julian Foad <ju...@btopenworld.com> writes:
>
> > The MAC OSX buildbot is failing because of a seg-fault that occurs in
> > merge_tests.py 59. (See for example this recent failure email
> > <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912> and follow the link to "Full details".)
> >
> > Can a MAC user post a stack trace (including parameter values) of this
> > failure? It might help one of us to debug it. I will try if I can see a
> > stack trace.
>
> I don't have a Mac, but using valgrind on Linux I get:
Hey Philip,
can you run the same for merge_test 56 (or show me how you run svn
tests in valgrind)? I suspect that test may have similar problems.
Thanks,
Stefan
Re: MAC OSX stack trace, please, for commit-tests.py 59
Posted by Philip Martin <ph...@codematters.co.uk>.
Julian Foad <ju...@btopenworld.com> writes:
> The MAC OSX buildbot is failing because of a seg-fault that occurs in
> merge_tests.py 59. (See for example this recent failure email
> <http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=2371912> and follow the link to "Full details".)
>
> Can a MAC user post a stack trace (including parameter values) of this
> failure? It might help one of us to debug it. I will try if I can see a
> stack trace.
I don't have a Mac, but using valgrind on Linux I get:
==22392== Conditional jump or move depends on uninitialised value(s)
==22392== at 0x30210143EF: find_entry (in /usr/lib/libapr-1.so.0.2.12)
==22392== by 0x30210146D5: apr_hash_set (in /usr/lib/libapr-1.so.0.2.12)
==22392== by 0x4EB13B8: entries_write_body (entries.c:2363)
==22392== by 0x4EB1AF2: entries_write (entries.c:2469)
==22392== by 0x4EB313E: svn_wc__tweak_entry (entries.c:3150)
==22392== by 0x4E92BD6: tweak_entries (adm_ops.c:115)
==22392== by 0x4E9347A: svn_wc__do_update_cleanup (adm_ops.c:293)
==22392== by 0x4E96D17: svn_wc_add3 (adm_ops.c:1618)
==22392== by 0x4C2E5D7: repos_to_wc_copy_single (copy.c:1368)
==22392== by 0x4C2F848: repos_to_wc_copy (copy.c:1662)
==22392== by 0x4C307A6: try_copy (copy.c:1968)
==22392== by 0x4C308D5: svn_client_copy5 (copy.c:2000)
==22392==
==22392== Conditional jump or move depends on uninitialised value(s)
==22392== at 0x30210146EB: apr_hash_set (in /usr/lib/libapr-1.so.0.2.12)
==22392== by 0x4EB13B8: entries_write_body (entries.c:2363)
==22392== by 0x4EB1AF2: entries_write (entries.c:2469)
==22392== by 0x4EB313E: svn_wc__tweak_entry (entries.c:3150)
==22392== by 0x4E92BD6: tweak_entries (adm_ops.c:115)
==22392== by 0x4E9347A: svn_wc__do_update_cleanup (adm_ops.c:293)
==22392== by 0x4E96D17: svn_wc_add3 (adm_ops.c:1618)
==22392== by 0x4C2E5D7: repos_to_wc_copy_single (copy.c:1368)
==22392== by 0x4C2F848: repos_to_wc_copy (copy.c:1662)
==22392== by 0x4C307A6: try_copy (copy.c:1968)
==22392== by 0x4C308D5: svn_client_copy5 (copy.c:2000)
==22392== by 0x40B4AC: svn_cl__copy (copy-cmd.c:139)
==22392==
==22392== Conditional jump or move depends on uninitialised value(s)
==22392== at 0x30210146EB: apr_hash_set (in /usr/lib/libapr-1.so.0.2.12)
==22392== by 0x4EB13B8: entries_write_body (entries.c:2363)
==22392== by 0x4EB1AF2: entries_write (entries.c:2469)
==22392== by 0x4EB2A4D: svn_wc__entry_modify (entries.c:2979)
==22392== by 0x4E94B56: mark_tree (adm_ops.c:904)
==22392== by 0x4E96D9D: svn_wc_add3 (adm_ops.c:1626)
==22392== by 0x4C2E5D7: repos_to_wc_copy_single (copy.c:1368)
==22392== by 0x4C2F848: repos_to_wc_copy (copy.c:1662)
==22392== by 0x4C307A6: try_copy (copy.c:1968)
==22392== by 0x4C308D5: svn_client_copy5 (copy.c:2000)
==22392== by 0x40B4AC: svn_cl__copy (copy-cmd.c:139)
==22392== by 0x4148EE: main (main.c:2115)
Traceback (most recent call last):
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 1149, in run
rc = self.pred.run(sandbox)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/testcase.py", line 200, in run
return self._delegate.run(sandbox)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/testcase.py", line 129, in run
return self.func(sandbox)
File "../../../../src/subversion/tests/cmdline/merge_tests.py", line 6814, in merge_to_out_of_date_target
wc_disk, wc_status = set_up_branch(sbox, False, 1)
File "../../../../src/subversion/tests/cmdline/merge_tests.py", line 4611, in set_up_branch
copy_A('A_COPY', i + 2)
File "../../../../src/subversion/tests/cmdline/merge_tests.py", line 4601, in copy_A
dest_name))
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/actions.py", line 207, in run_and_verify_svn
expected_exit, *varargs)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/actions.py", line 240, in run_and_verify_svn2
exit_code, out, err = main.run_svn(want_err, *varargs)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 587, in run_svn
*(_with_auth(_with_config_dir(varargs))))
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 365, in run_command
None, *varargs)
File "/home/pm/sw/subversion/src/subversion/tests/cmdline/svntest/main.py", line 520, in run_command_stdin
raise Failure
Failure
FAIL: merge_tests.py 59: merge to ood path can lead to inaccurate mergeinfo
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372007