You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Beranek <jo...@redux.org.uk> on 2011/03/03 18:54:04 UTC
Breakage on trunk?
Hi,
This afternoon, I checked out the trunk from Subversion in order to
build a dev system running 1.7.
I updated a sandbox I had lying around, made it 'extraclean', built and
installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
/usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
Subversion.
All of this was done on a Fedora 14 x86_64 system. What I got for my
troubles was assertion failures when trying a commit with either
Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
subversion/libsvn_subr/svn_temp_serializer.c:282:
svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
Am I doing something stupid, or is there some breakage on the trunk?
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Thu, Mar 3, 2011 at 12:30 PM, Philip Martin
<ph...@wandisco.com> wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> This afternoon, I checked out the trunk from Subversion in order to
>> build a dev system running 1.7.
>>
>> I updated a sandbox I had lying around, made it 'extraclean', built and
>> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
>> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
>> Subversion.
>>
>> All of this was done on a Fedora 14 x86_64 system. What I got for my
>> troubles was assertion failures when trying a commit with either
>> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
>>
>> subversion/libsvn_subr/svn_temp_serializer.c:282:
>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>
>> Am I doing something stupid, or is there some breakage on the trunk?
>
> Some, but not that.
>
> http://subversion.apache.org/buildbot
Those are related to a change which wasn't compatible with APR 0.9.
-Hyrum
> Do the regression tests pass on your machine?
>
> --
> Philip
>
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/2011 19:38, John Beranek wrote:
> On 03/03/2011 18:30, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> This afternoon, I checked out the trunk from Subversion in order to
>>> build a dev system running 1.7.
>>>
>>> I updated a sandbox I had lying around, made it 'extraclean', built and
>>> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
>>> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
>>> Subversion.
>>>
>>> All of this was done on a Fedora 14 x86_64 system. What I got for my
>>> troubles was assertion failures when trying a commit with either
>>> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
I get a seemingly identical output from the tests if I rebuild on my
home openSUSE 11.3 i386 system:
$ make check
Running tests in auth-test [1/88].............................success
Running tests in cache-test [2/88]............................success
Running tests in checksum-test [3/88].........................success
Running tests in client-test [4/88]...........................FAILURE
Running tests in compat-test [5/88]...........................success
Running tests in config-test [6/88]...........................success
Running tests in db-test [7/88]...............................success
Running tests in diff-diff3-test [8/88].......................success
Running tests in dirent_uri-test [9/88].......................success
Running tests in entries-compat-test [10/88]..................success
Running tests in eol-test [11/88].............................success
Running tests in error-test [12/88]...........................success
Running tests in fs-pack-test [13/88].........................FAILURE
Running tests in fs-test [14/88]..............................FAILURE
Running tests in hashdump-test [15/88]........................success
Running tests in locks-test [16/88]...........................FAILURE
Running tests in mergeinfo-test [17/88].......................success
Running tests in op-depth-test [18/88]........................FAILURE
Running tests in opt-test [19/88].............................success
Running tests in parse-diff-test [20/88]......................success
Running tests in path-test [21/88]............................success
Running tests in pristine-store-test [22/88]..................FAILURE
Running tests in ra-local-test [23/88]........................FAILURE
Running tests in random-test [24/88]..........................success
Running tests in repos-test [25/88]...........................FAILURE
Running tests in revision-test [26/88]........................success
Running tests in skel-test [27/88]............................success
Running tests in stream-test [28/88]..........................success
Running tests in string-test [29/88]..........................success
Running tests in subst_translate-test [30/88].................success
Running tests in target-test [31/88]..........................success
Running tests in time-test [32/88]............................success
Running tests in translate-test [33/88].......................success
Running tests in tree-conflict-data-test [34/88]..............success
Running tests in utf-test [35/88].............................success
Running tests in window-test [36/88]..........................success
Running tests in authz_tests.py [37/88]make: *** [check] Error 1
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Hyrum K Wright <hy...@hyrumwright.org> writes:
>
>> Random observation from the sideline:
>> It appears that the failure is happening in the code which Stefan^2
>> recently merged. As this code is relatively new, it may not have been
>> very well exercised on the branch or on trunk. We shouldn't discount
>> this being a real bug on trunk.
>
> Yes, I suspect the FSFS performance stuff.
Well, it's not FSFS specific since "client-test --fs-type=bdb 3" also
shows errors.
--
Philip
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
Hyrum K Wright <hy...@hyrumwright.org> writes:
> Random observation from the sideline:
> It appears that the failure is happening in the code which Stefan^2
> recently merged. As this code is relatively new, it may not have been
> very well exercised on the branch or on trunk. We shouldn't discount
> this being a real bug on trunk.
Yes, I suspect the FSFS performance stuff.
--
Philip
Re: Breakage on trunk?
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Thu, Mar 3, 2011 at 2:48 PM, Philip Martin
<ph...@wandisco.com> wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> On 03/03/2011 20:01, Philip Martin wrote:
>>> John Beranek <jo...@redux.org.uk> writes:
>>>
>>>> On 03/03/2011 18:30, Philip Martin wrote:
>>>>> John Beranek <jo...@redux.org.uk> writes:
>>>>>
>>>>>>
>>>>>> Am I doing something stupid, or is there some breakage on the trunk?
>>>>>
>>>
>>> That looks like a problem with your build, tests.log might help but you
>>> probably need to build with debug info and debug one of the failing
>>> tests with gdb.
>>
>> Surprise surprise - the same assertion I get in svnserve/mod_dav_svn:
>>
>> START: client-test
>> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>
> Do you build with BDB support? If so are the 'make bdbcheck' results
> better? There may still be FSFS failures as some tests will not use
> BDB, but if there are fewer it could point to a FSFS problem.
Random observation from the sideline:
It appears that the failure is happening in the code which Stefan^2
recently merged. As this code is relatively new, it may not have been
very well exercised on the branch or on trunk. We shouldn't discount
this being a real bug on trunk.
-Hyrum
Re: Breakage on trunk?
Posted by Julian Foad <ju...@wandisco.com>.
On Fri, 2011-03-04 at 11:43 +0000, John Beranek wrote:
> On 04/03/11 11:32, Julian Foad wrote:
> > On Thu, 2011-03-03, John Beranek wrote:
> >> Running tests in auth-test [1/88].............................success
> >> Running tests in cache-test [2/88]............................success
> >> Running tests in checksum-test [3/88].........................success
> >> Running tests in client-test [4/88]...........................success
> >> Running tests in compat-test [5/88]...........................success
> >> Running tests in config-test [6/88]...........................success
> >> Running tests in db-test [7/88]...............................success
> >> Running tests in diff-diff3-test [8/88].......................success
> >> Running tests in dirent_uri-test [9/88].......................success
> >> Running tests in entries-compat-test [10/88]..................success
> >> Running tests in eol-test [11/88].............................success
> >> Running tests in error-test [12/88]...........................success
> >> Running tests in fs-pack-test [13/88].........................success
> >> Running tests in fs-test [14/88]..............................success
> >> Running tests in hashdump-test [15/88]........................success
> >> Running tests in locks-test [16/88]...........................success
> >> Running tests in mergeinfo-test [17/88].......................success
> >> Running tests in op-depth-test [18/88]........................success
> >> Running tests in opt-test [19/88].............................success
> >> Running tests in parse-diff-test [20/88]......................success
> >> Running tests in path-test [21/88]............................success
> >> Running tests in pristine-store-test [22/88]..................FAILURE
> >
> > I recently changed the pristine-store handling. I'll see if I can spot
> > anything wrong there. Please could you show me
> >
> > $ grep --context=10 "^FAIL:.*pristine-store-test" tests.log
>
> PASS: lt-path-test 23: test svn_path_local_style
> PASS: lt-path-test 24: test svn_path_internal_style
> END: path-test
> ELAPSED: path-test 0:00:00.018077
>
> START: pristine-store-test
> PASS: lt-pristine-store-test 1: pristine_write_read
> PASS: lt-pristine-store-test 2: pristine_get_translated
> PASS: lt-pristine-store-test 3: pristine_delete_while_open
> svn_tests: E200006: err != NULL
> FAIL: lt-pristine-store-test 4: reject_mismatching_text
Thanks John. I remember now, somebody already pointed out to me that
this test would fail on a release-mode build. Sorry about that. I'll
fix it, but the most interesting point is that this particular one
probably isn't related to the other failures.
- Julian
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 11:32, Julian Foad wrote:
> On Thu, 2011-03-03, John Beranek wrote:
>> Running tests in auth-test [1/88].............................success
>> Running tests in cache-test [2/88]............................success
>> Running tests in checksum-test [3/88].........................success
>> Running tests in client-test [4/88]...........................success
>> Running tests in compat-test [5/88]...........................success
>> Running tests in config-test [6/88]...........................success
>> Running tests in db-test [7/88]...............................success
>> Running tests in diff-diff3-test [8/88].......................success
>> Running tests in dirent_uri-test [9/88].......................success
>> Running tests in entries-compat-test [10/88]..................success
>> Running tests in eol-test [11/88].............................success
>> Running tests in error-test [12/88]...........................success
>> Running tests in fs-pack-test [13/88].........................success
>> Running tests in fs-test [14/88]..............................success
>> Running tests in hashdump-test [15/88]........................success
>> Running tests in locks-test [16/88]...........................success
>> Running tests in mergeinfo-test [17/88].......................success
>> Running tests in op-depth-test [18/88]........................success
>> Running tests in opt-test [19/88].............................success
>> Running tests in parse-diff-test [20/88]......................success
>> Running tests in path-test [21/88]............................success
>> Running tests in pristine-store-test [22/88]..................FAILURE
>
> I recently changed the pristine-store handling. I'll see if I can spot
> anything wrong there. Please could you show me
>
> $ grep --context=10 "^FAIL:.*pristine-store-test" tests.log
PASS: lt-path-test 23: test svn_path_local_style
PASS: lt-path-test 24: test svn_path_internal_style
END: path-test
ELAPSED: path-test 0:00:00.018077
START: pristine-store-test
PASS: lt-pristine-store-test 1: pristine_write_read
PASS: lt-pristine-store-test 2: pristine_get_translated
PASS: lt-pristine-store-test 3: pristine_delete_while_open
svn_tests: E200006: err != NULL
FAIL: lt-pristine-store-test 4: reject_mismatching_text
END: pristine-store-test
ELAPSED: pristine-store-test 0:00:03.871989
START: ra-local-test
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Julian Foad <ju...@wandisco.com>.
On Thu, 2011-03-03, John Beranek wrote:
> Running tests in auth-test [1/88].............................success
> Running tests in cache-test [2/88]............................success
> Running tests in checksum-test [3/88].........................success
> Running tests in client-test [4/88]...........................success
> Running tests in compat-test [5/88]...........................success
> Running tests in config-test [6/88]...........................success
> Running tests in db-test [7/88]...............................success
> Running tests in diff-diff3-test [8/88].......................success
> Running tests in dirent_uri-test [9/88].......................success
> Running tests in entries-compat-test [10/88]..................success
> Running tests in eol-test [11/88].............................success
> Running tests in error-test [12/88]...........................success
> Running tests in fs-pack-test [13/88].........................success
> Running tests in fs-test [14/88]..............................success
> Running tests in hashdump-test [15/88]........................success
> Running tests in locks-test [16/88]...........................success
> Running tests in mergeinfo-test [17/88].......................success
> Running tests in op-depth-test [18/88]........................success
> Running tests in opt-test [19/88].............................success
> Running tests in parse-diff-test [20/88]......................success
> Running tests in path-test [21/88]............................success
> Running tests in pristine-store-test [22/88]..................FAILURE
I recently changed the pristine-store handling. I'll see if I can spot
anything wrong there. Please could you show me
$ grep --context=10 "^FAIL:.*pristine-store-test" tests.log
Thanks.
- Julian
> Running tests in ra-local-test [23/88]........................success
> Running tests in random-test [24/88]..........................success
> Running tests in repos-test [25/88]...........................success
> Running tests in revision-test [26/88]........................success
> Running tests in skel-test [27/88]............................success
> Running tests in stream-test [28/88]..........................success
> Running tests in string-test [29/88]..........................success
> Running tests in subst_translate-test [30/88].................success
> Running tests in target-test [31/88]..........................success
> Running tests in time-test [32/88]............................success
> Running tests in translate-test [33/88].......................success
> Running tests in tree-conflict-data-test [34/88]..............success
> Running tests in utf-test [35/88].............................success
> Running tests in window-test [36/88]..........................success
> Running tests in authz_tests.py [37/88].......................success
> Running tests in autoprop_tests.py [38/88]....................success
> Running tests in basic_tests.py [39/88].......................FAILURE
> Running tests in blame_tests.py [40/88].......................success
> Running tests in cat_tests.py [41/88].........................FAILURE
> Running tests in changelist_tests.py [42/88]..................success
> Running tests in checkout_tests.py [43/88]....................success
>
> John.
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/2011 20:48, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> On 03/03/2011 20:01, Philip Martin wrote:
>>> John Beranek <jo...@redux.org.uk> writes:
>>>
>>>> On 03/03/2011 18:30, Philip Martin wrote:
>>>>> John Beranek <jo...@redux.org.uk> writes:
>>>>>
>>>>>>
>>>>>> Am I doing something stupid, or is there some breakage on the trunk?
>>>>>
>>>
>>> That looks like a problem with your build, tests.log might help but you
>>> probably need to build with debug info and debug one of the failing
>>> tests with gdb.
>>
>> Surprise surprise - the same assertion I get in svnserve/mod_dav_svn:
>>
>> START: client-test
>> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>
> Do you build with BDB support? If so are the 'make bdbcheck' results
> better? There may still be FSFS failures as some tests will not use
> BDB, but if there are fewer it could point to a FSFS problem.
Tests are still running, but it's certainly better:
$ make bdbcheck
make[1]: Entering directory `/home/jberanek/builds/subversion-trunk'
Running tests in auth-test [1/88].............................success
Running tests in cache-test [2/88]............................success
Running tests in checksum-test [3/88].........................success
Running tests in client-test [4/88]...........................success
Running tests in compat-test [5/88]...........................success
Running tests in config-test [6/88]...........................success
Running tests in db-test [7/88]...............................success
Running tests in diff-diff3-test [8/88].......................success
Running tests in dirent_uri-test [9/88].......................success
Running tests in entries-compat-test [10/88]..................success
Running tests in eol-test [11/88].............................success
Running tests in error-test [12/88]...........................success
Running tests in fs-pack-test [13/88].........................success
Running tests in fs-test [14/88]..............................success
Running tests in hashdump-test [15/88]........................success
Running tests in locks-test [16/88]...........................success
Running tests in mergeinfo-test [17/88].......................success
Running tests in op-depth-test [18/88]........................success
Running tests in opt-test [19/88].............................success
Running tests in parse-diff-test [20/88]......................success
Running tests in path-test [21/88]............................success
Running tests in pristine-store-test [22/88]..................FAILURE
Running tests in ra-local-test [23/88]........................success
Running tests in random-test [24/88]..........................success
Running tests in repos-test [25/88]...........................success
Running tests in revision-test [26/88]........................success
Running tests in skel-test [27/88]............................success
Running tests in stream-test [28/88]..........................success
Running tests in string-test [29/88]..........................success
Running tests in subst_translate-test [30/88].................success
Running tests in target-test [31/88]..........................success
Running tests in time-test [32/88]............................success
Running tests in translate-test [33/88].......................success
Running tests in tree-conflict-data-test [34/88]..............success
Running tests in utf-test [35/88].............................success
Running tests in window-test [36/88]..........................success
Running tests in authz_tests.py [37/88].......................success
Running tests in autoprop_tests.py [38/88]....................success
Running tests in basic_tests.py [39/88].......................FAILURE
Running tests in blame_tests.py [40/88].......................success
Running tests in cat_tests.py [41/88].........................FAILURE
Running tests in changelist_tests.py [42/88]..................success
Running tests in checkout_tests.py [43/88]....................success
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> On 03/03/2011 20:01, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> On 03/03/2011 18:30, Philip Martin wrote:
>>>> John Beranek <jo...@redux.org.uk> writes:
>>>>
>>>>>
>>>>> Am I doing something stupid, or is there some breakage on the trunk?
>>>>
>>
>> That looks like a problem with your build, tests.log might help but you
>> probably need to build with debug info and debug one of the failing
>> tests with gdb.
>
> Surprise surprise - the same assertion I get in svnserve/mod_dav_svn:
>
> START: client-test
> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
Do you build with BDB support? If so are the 'make bdbcheck' results
better? There may still be FSFS failures as some tests will not use
BDB, but if there are fewer it could point to a FSFS problem.
--
Philip
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> /me 's workaround has been $prefix/apache2/build/libtool --mode=execute env SHELL=$SHELL gdb --args ./subversion/svn/svn
That's the proper, platform-independent way to do it.
> (but the lt-$basename should be easier to work with)
This works on Linux. It may not work on WeirdOS.
--
Philip
Re: Breakage on trunk?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Fri, Mar 04, 2011 at 11:18:33 +0000:
> John Beranek <jo...@redux.org.uk> writes:
>
> > Oh, this is for a run of an installed copy of svnserve, as I don't have a:
> >
> > subversion/tests/libsvn_client/.libs/lt-client-test
> >
> > only:
> >
> > subversion/tests/libsvn_client/client-test
> > [A wrapper script I can't run with gdb]
> >
> > subversion/tests/libsvn_client/.libs/client-test
> > [An executable that doesn't find its libraries]
>
> Building creates the libtool wrapper scipt client-test and the
> executable .libs/client-tests. The executable is one that will be
> installed and is linked to libraries in the install path.
>
> If you run the libtool wrapper script it creates a second, temporary
> executable .libs/lt-client-test. This is linked to libraries in the
> build directory. This is one you debug.
>
Thanks for the overview!
/me 's workaround has been $prefix/apache2/build/libtool --mode=execute env SHELL=$SHELL gdb --args ./subversion/svn/svn
(but the lt-$basename should be easier to work with)
> --
> Philip
Re: Breakage on trunk?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[ pastebins may disappear someday, and aren't indexed by the list archives, so... ]
John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +0000:
> On 05/03/2011 20:04, John Beranek wrote:
> > On 05/03/2011 18:33, Philip Martin wrote:
> >> Stefan Fuhrmann <eq...@web.de> writes:
> >>
> >>> I suspect that -fstrict-aliasing (or something similar)
> >>> might have broken svn_temp_deserializer__resolve().
> >>>
> >>> r1078256 tries to circumvent that.
> >>
> >> John should be able to confirm that by testing some revision less than
> >> r1078256 using EXTRA_CFLAGS='-O2 -fno-strict-aliasing'
>
> OK, completed full "make check", older code with -fno-strict-aliasing:
>
...
> Results of "grep --before-context=10 "^FAIL:" tests.log":
> http://pastebin.com/7y3Qjtnz
>
[[[
return self.func(sandbox)
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/basic_tests.py", line 2762, in ls_multiple_and_non_existent_targets
multiple_wc_targets()
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/basic_tests.py", line 2735, in multiple_wc_targets
'"%s"' % (expected_err, "".join(error)))
Failure: ls failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: The node '/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-57/non-existent' was not found.
svn: E200009: Could not list all targets because some targets don't exist
"
FAIL: basic_tests.py 57: ls multiple and non-existent targets
--
rc = self.pred.run(sandbox)
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svntest/testcase.py", line 176, in run
return self.func(sandbox)
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/basic_tests.py", line 2794, in add_multiple_targets
'"%s"' % (expected_err, "".join(error)))
Failure: add failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: '/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-58/non-existent' not found
svn: E200009: Could not add all targets because some targets don't exist
"
FAIL: basic_tests.py 58: add multiple targets
--
multiple_wc_targets()
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/basic_tests.py", line 2830, in multiple_wc_targets
'"%s"' % (expected_err, "".join(error)))
Failure: info failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: The node '/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-59/non-existent' was not found.
svn: E200009: Could not display info for all targets because some targets don't exist
"
FAIL: basic_tests.py 59: info multiple targets
--
return self.func(sandbox)
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/basic_tests.py", line 2917, in blame_multiple_targets
multiple_wc_targets()
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/basic_tests.py", line 2887, in multiple_wc_targets
'"%s"' % (expected_err, "".join(error)))
Failure: blame failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: The node '/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-60/non-existent' was not found.
svn: E200009: Could not perform blame on all targets because some targets don't exist
"
FAIL: basic_tests.py 60: blame multiple target
--
File "/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/cat_tests.py", line 176, in cat_skip_uncattable
(expected_err3, "".join(error)))
Failure: Cat failed: expected error "svn: warning: W195007: '\/export\/home\/jberanek\/builds\/subversion\-svn\-bisect\/subversion\/tests\/cmdline\/svn\-test\-work\/working\_copies\/cat\_tests\-5\/A\/D\/G' refers to a directory
svn: warning: W200005: '\/export\/home\/jberanek\/builds\/subversion\-svn\-bisect\/subversion\/tests\/cmdline\/svn\-test\-work\/working\_copies\/cat\_tests\-5\/A\/D\/new' is not under version control
.*
svn: E200009: Could not cat all targets because some targets don't exist
", but received "svn: warning: W195007: '/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svn-test-work/working_copies/cat_tests-5/A/D/G' refers to a directory
svn: warning: W200005: '/export/home/jberanek/builds/subversion-svn-bisect/subversion/tests/cmdline/svn-test-work/working_copies/cat_tests-5/A/D/new' is not under version control
svn: E200009: Could not cat all targets because some targets don't exist
"
FAIL: cat_tests.py 5: cat should skip uncattable resources
]]]
> and with the updated code:
...
> Results of "grep --before-context=10 "^FAIL:" tests.log":
> http://pastebin.com/dtM06GYq
[[[
return self.func(sandbox)
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/basic_tests.py", line 2762, in ls_multiple_and_non_existent_targets
multiple_wc_targets()
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/basic_tests.py", line 2735, in multiple_wc_targets
'"%s"' % (expected_err, "".join(error)))
Failure: ls failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: The node '/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-57/non-existent' was not found.
svn: E200009: Could not list all targets because some targets don't exist
"
FAIL: basic_tests.py 57: ls multiple and non-existent targets
--
rc = self.pred.run(sandbox)
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svntest/testcase.py", line 176, in run
return self.func(sandbox)
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/basic_tests.py", line 2794, in add_multiple_targets
'"%s"' % (expected_err, "".join(error)))
Failure: add failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: '/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-58/non-existent' not found
svn: E200009: Could not add all targets because some targets don't exist
"
FAIL: basic_tests.py 58: add multiple targets
--
multiple_wc_targets()
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/basic_tests.py", line 2830, in multiple_wc_targets
'"%s"' % (expected_err, "".join(error)))
Failure: info failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: The node '/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-59/non-existent' was not found.
svn: E200009: Could not display info for all targets because some targets don't exist
"
FAIL: basic_tests.py 59: info multiple targets
--
return self.func(sandbox)
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/basic_tests.py", line 2917, in blame_multiple_targets
multiple_wc_targets()
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/basic_tests.py", line 2887, in multiple_wc_targets
'"%s"' % (expected_err, "".join(error)))
Failure: blame failed: expected error ".*W155010.*
.*
.*E200009.*", but received "svn: warning: W155010: The node '/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svn-test-work/working_copies/basic_tests-60/non-existent' was not found.
svn: E200009: Could not perform blame on all targets because some targets don't exist
"
FAIL: basic_tests.py 60: blame multiple target
--
File "/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/cat_tests.py", line 176, in cat_skip_uncattable
(expected_err3, "".join(error)))
Failure: Cat failed: expected error "svn: warning: W195007: '\/export\/home\/jberanek\/builds\/subversion\-svn\/subversion\/tests\/cmdline\/svn\-test\-work\/working\_copies\/cat\_tests\-5\/A\/D\/G' refers to a directory
svn: warning: W200005: '\/export\/home\/jberanek\/builds\/subversion\-svn\/subversion\/tests\/cmdline\/svn\-test\-work\/working\_copies\/cat\_tests\-5\/A\/D\/new' is not under version control
.*
svn: E200009: Could not cat all targets because some targets don't exist
", but received "svn: warning: W195007: '/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svn-test-work/working_copies/cat_tests-5/A/D/G' refers to a directory
svn: warning: W200005: '/export/home/jberanek/builds/subversion-svn/subversion/tests/cmdline/svn-test-work/working_copies/cat_tests-5/A/D/new' is not under version control
svn: E200009: Could not cat all targets because some targets don't exist
"
FAIL: cat_tests.py 5: cat should skip uncattable resources
]]]
>
>
> John.
>
> --
> John Beranek To generalise is to be an idiot.
> http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
John Beranek wrote on Sat, Mar 05, 2011 at 21:56:22 +0000:
> On 05/03/2011 21:47, Daniel Shahaf wrote:
> > John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +0000:
> >> Results of "grep --before-context=10 "^FAIL:" tests.log":
> >
> > In case you aren't aware: after 'make check' has finished, you can look
> > at fails.log to see just the verbose test log only for failed tests.
>
> Ah, handy. Also, I did wonder about the list ettiquete about pastebins,
> large emails, attachments...
13KB isn't that large; we often have posts with over 13KB of quoted text...
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 05/03/2011 21:47, Daniel Shahaf wrote:
> John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +0000:
>> Results of "grep --before-context=10 "^FAIL:" tests.log":
>
> In case you aren't aware: after 'make check' has finished, you can look
> at fails.log to see just the verbose test log only for failed tests.
Ah, handy. Also, I did wonder about the list ettiquete about pastebins,
large emails, attachments...
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
John Beranek wrote on Sat, Mar 05, 2011 at 21:02:34 +0000:
> Results of "grep --before-context=10 "^FAIL:" tests.log":
In case you aren't aware: after 'make check' has finished, you can look
at fails.log to see just the verbose test log only for failed tests.
Re: Breakage on trunk?
Posted by Stefan Fuhrmann <eq...@web.de>.
On 05.03.2011 22:21, Branko Čibej wrote:
> On 05.03.2011 19:52, Stefan Fuhrmann wrote:
>> On 05.03.2011 11:55, Branko Čibej wrote:
>>> On 05.03.2011 11:34, Stefan Fuhrmann wrote:
>>>> I suspect that -fstrict-aliasing (or something similar)
>>>> might have broken svn_temp_deserializer__resolve().
>>>>
>>>> r1078256 tries to circumvent that.
>>> Ahem. Type casting will not help, at least GCC's optimizer sees right
>>> through them.
>> Well, my hypothesis is that the optimizer breaks the
>> code *due to* the casting:
>>
>> *(const char**)ptr = buffer + (size_t)*ptr;
>> assert(*ptr> buffer);
>>
>> might become:
>>
>> temp1 = *ptr;
>> *ptr = buffer + temp1;
>> assert(temp1> buffer);
> Oh I see, you're doing pointer/offset fixups in shared memory. Yah.
> Have you considered using a union { const char*, size_t } instead of a
> pointer? That /should/ be safe even with strict aliasing, as long as you
> always read the union member that you last wrote (which should work fine
> given what you're doing). This way you avoid all the casts, too.
>
>> I would consider that a bug
> ... but it's not, given strict-aliasing semantics ...
You are right. I was simply surprised that these semantics
would cause the compiler to consider two occurrences of
the same address (pointer) within one statement as unrelated.
Of course there is no consistent way one could define a
meaningful scope in which that semantics would not apply.
Just hadn't thought about it too deeply ...
-- Stefan^2.
Re: Breakage on trunk?
Posted by Branko Čibej <br...@e-reka.si>.
On 05.03.2011 19:52, Stefan Fuhrmann wrote:
> On 05.03.2011 11:55, Branko Čibej wrote:
>> On 05.03.2011 11:34, Stefan Fuhrmann wrote:
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
>>> r1078256 tries to circumvent that.
>> Ahem. Type casting will not help, at least GCC's optimizer sees right
>> through them.
> Well, my hypothesis is that the optimizer breaks the
> code *due to* the casting:
>
> *(const char**)ptr = buffer + (size_t)*ptr;
> assert(*ptr > buffer);
>
> might become:
>
> temp1 = *ptr;
> *ptr = buffer + temp1;
> assert(temp1 > buffer);
Oh I see, you're doing pointer/offset fixups in shared memory. Yah.
Have you considered using a union { const char*, size_t } instead of a
pointer? That /should/ be safe even with strict aliasing, as long as you
always read the union member that you last wrote (which should work fine
given what you're doing). This way you avoid all the casts, too.
> I would consider that a bug
... but it's not, given strict-aliasing semantics ...
-- Brane
Re: Breakage on trunk?
Posted by Stefan Fuhrmann <eq...@web.de>.
On 05.03.2011 11:55, Branko Čibej wrote:
> On 05.03.2011 11:34, Stefan Fuhrmann wrote:
>> I suspect that -fstrict-aliasing (or something similar)
>> might have broken svn_temp_deserializer__resolve().
>>
>> r1078256 tries to circumvent that.
> Ahem. Type casting will not help, at least GCC's optimizer sees right
> through them.
Well, my hypothesis is that the optimizer breaks the
code *due to* the casting:
*(const char**)ptr = buffer + (size_t)*ptr;
assert(*ptr > buffer);
might become:
temp1 = *ptr;
*ptr = buffer + temp1;
assert(temp1 > buffer);
I would consider that a bug but I rearranged the code
such that it should produce the desired result even
in the presence of these issues:
const char *target = buffer + *(size_t*)ptr1;
assert(target > buffer); // this is the key
*(const char**)ptr = target;
> The thing to do is to not play silly buggers with type
> punning in the first place. :)
Sometimes you have to. But one should strive to
limit these instances.
-- Stefan^2.
Re: Breakage on trunk?
Posted by Branko Čibej <br...@e-reka.si>.
On 05.03.2011 11:34, Stefan Fuhrmann wrote:
> I suspect that -fstrict-aliasing (or something similar)
> might have broken svn_temp_deserializer__resolve().
>
> r1078256 tries to circumvent that.
Ahem. Type casting will not help, at least GCC's optimizer sees right
through them. The thing to do is to not play silly buggers with type
punning in the first place. :)
-- Brane
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 05/03/2011 20:04, John Beranek wrote:
> On 05/03/2011 18:33, Philip Martin wrote:
>> Stefan Fuhrmann <eq...@web.de> writes:
>>
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
>>> r1078256 tries to circumvent that.
>>
>> John should be able to confirm that by testing some revision less than
>> r1078256 using EXTRA_CFLAGS='-O2 -fno-strict-aliasing'
OK, completed full "make check", older code with -fno-strict-aliasing:
FAIL: basic_tests.py 57: ls multiple and non-existent targets
FAIL: basic_tests.py 58: add multiple targets
FAIL: basic_tests.py 59: info multiple targets
FAIL: basic_tests.py 60: blame multiple target
FAIL: cat_tests.py 5: cat should skip uncattable resources
Summary of test results:
1418 tests PASSED
40 tests SKIPPED
54 tests XFAILED (2 WORK-IN-PROGRESS)
5 tests FAILED
Results of "grep --before-context=10 "^FAIL:" tests.log":
http://pastebin.com/7y3Qjtnz
and with the updated code:
FAIL: basic_tests.py 57: ls multiple and non-existent targets
FAIL: basic_tests.py 58: add multiple targets
FAIL: basic_tests.py 59: info multiple targets
FAIL: basic_tests.py 60: blame multiple target
FAIL: cat_tests.py 5: cat should skip uncattable resources
Summary of test results:
1418 tests PASSED
40 tests SKIPPED
54 tests XFAILED (2 WORK-IN-PROGRESS)
5 tests FAILED
Results of "grep --before-context=10 "^FAIL:" tests.log":
http://pastebin.com/dtM06GYq
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 05/03/2011 20:04, John Beranek wrote:
> On 05/03/2011 18:33, Philip Martin wrote:
>> Stefan Fuhrmann <eq...@web.de> writes:
>>
>>> I suspect that -fstrict-aliasing (or something similar)
>>> might have broken svn_temp_deserializer__resolve().
>>>
>>> r1078256 tries to circumvent that.
>>
>> John should be able to confirm that by testing some revision less than
>> r1078256 using EXTRA_CFLAGS='-O2 -fno-strict-aliasing'
>
> Confirmed: that fixes the assertion error in client-test at least.
>
> Now, I can try the code fixes from Stefan.
Stefan's code fixes also solve the assertion failures on my home machine
(openSUSE 11.3 i586, GCC 4.5.0).
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 05/03/2011 18:33, Philip Martin wrote:
> Stefan Fuhrmann <eq...@web.de> writes:
>
>> I suspect that -fstrict-aliasing (or something similar)
>> might have broken svn_temp_deserializer__resolve().
>>
>> r1078256 tries to circumvent that.
>
> John should be able to confirm that by testing some revision less than
> r1078256 using EXTRA_CFLAGS='-O2 -fno-strict-aliasing'
Confirmed: that fixes the assertion error in client-test at least.
Now, I can try the code fixes from Stefan.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Fuhrmann <eq...@web.de> writes:
> I suspect that -fstrict-aliasing (or something similar)
> might have broken svn_temp_deserializer__resolve().
>
> r1078256 tries to circumvent that.
John should be able to confirm that by testing some revision less than
r1078256 using EXTRA_CFLAGS='-O2 -fno-strict-aliasing'
--
Philip
Re: Breakage on trunk?
Posted by Stefan Fuhrmann <eq...@web.de>.
On 05.03.2011 01:56, Stefan Fuhrmann wrote:
> On 05.03.2011 01:16, John Beranek wrote:
>> On 04/03/2011 23:02, Stefan Fuhrmann wrote:
>>> On 04.03.2011 12:32, John Beranek wrote:
>>>> On 04/03/11 11:18, Philip Martin wrote:
>>>>> John Beranek<jo...@redux.org.uk> writes:
>>>>>
>>>>>> Oh, this is for a run of an installed copy of svnserve, as I don't
>>>>>> have a:
>>>>>>
>>>>>> subversion/tests/libsvn_client/.libs/lt-client-test
>>>>>>
>>>>>> only:
>>>>>>
>>>>>> subversion/tests/libsvn_client/client-test
>>>>>> [A wrapper script I can't run with gdb]
>>>>>>
>>>>>> subversion/tests/libsvn_client/.libs/client-test
>>>>>> [An executable that doesn't find its libraries]
>>>>> Building creates the libtool wrapper scipt client-test and the
>>>>> executable .libs/client-tests. The executable is one that will be
>>>>> installed and is linked to libraries in the install path.
>>>>>
>>>>> If you run the libtool wrapper script it creates a second, temporary
>>>>> executable .libs/lt-client-test. This is linked to libraries in the
>>>>> build directory. This is one you debug.
>>>> Oh, I _see_. :)
>>>>
>>>> #0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
>>>> #1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
>>>> #2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
>>>> #3 0x00007ffff5b88d0b in svn_temp_deserializer__resolve (
>>>> buffer=<value optimized out>, ptr=<value optimized out>)
>>>> at subversion/libsvn_subr/svn_temp_serializer.c:282
>>>> #4 0x00007ffff6403606 in svn_fs_fs__id_deserialize (
>>>> buffer=<value optimized out>, id=0x7912b0)
>>>> at subversion/libsvn_fs_fs/id.c:387
>>>> #5 0x00007ffff63f4743 in svn_fs_fs__dag_deserialize
>>>> (out=0x7fffffffd750,
>>>> data=0x7912a8 "", data_len=<value optimized out>,
>>>> pool=<value optimized out>) at
>>>> subversion/libsvn_fs_fs/dag.c:1111
>>> This is the first call to any de-serializer function
>>> right after the raw data has been read cache.
>>>
>>> So, there is a chance that the data either got
>>> corrupted by the cache itself or was garbage
>>> even before that. Therefore, I added extensive
>>> consistency checks in r1078185 to be able to
>>> rule out the cache code itself.
>>>
>>> Please rebuild with -DDEBUG_CACHE_MEMBUFFER
>>> and retry.
>> Hmm, appears unchanged with this extra checking/debugging...
>>
>> John.
> That is good news. Assuming that the consistency check
> was actually enabled, we can rule out the cache for now.
> From my perspective, this leaves at least two possibilities:
>
> * compiler / optimizer issue
> -> a look at the assembly output should clear that one quickly
> * the data gets corrupted during serialization
> -> serializer may need even more assertions()
>
> -- Stefan^2.
>
I suspect that -fstrict-aliasing (or something similar)
might have broken svn_temp_deserializer__resolve().
r1078256 tries to circumvent that.
-- Stefan^2.
Re: Breakage on trunk?
Posted by Stefan Fuhrmann <eq...@web.de>.
On 05.03.2011 01:16, John Beranek wrote:
> On 04/03/2011 23:02, Stefan Fuhrmann wrote:
>> On 04.03.2011 12:32, John Beranek wrote:
>>> On 04/03/11 11:18, Philip Martin wrote:
>>>> John Beranek<jo...@redux.org.uk> writes:
>>>>
>>>>> Oh, this is for a run of an installed copy of svnserve, as I don't
>>>>> have a:
>>>>>
>>>>> subversion/tests/libsvn_client/.libs/lt-client-test
>>>>>
>>>>> only:
>>>>>
>>>>> subversion/tests/libsvn_client/client-test
>>>>> [A wrapper script I can't run with gdb]
>>>>>
>>>>> subversion/tests/libsvn_client/.libs/client-test
>>>>> [An executable that doesn't find its libraries]
>>>> Building creates the libtool wrapper scipt client-test and the
>>>> executable .libs/client-tests. The executable is one that will be
>>>> installed and is linked to libraries in the install path.
>>>>
>>>> If you run the libtool wrapper script it creates a second, temporary
>>>> executable .libs/lt-client-test. This is linked to libraries in the
>>>> build directory. This is one you debug.
>>> Oh, I _see_. :)
>>>
>>> #0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
>>> #1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
>>> #2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
>>> #3 0x00007ffff5b88d0b in svn_temp_deserializer__resolve (
>>> buffer=<value optimized out>, ptr=<value optimized out>)
>>> at subversion/libsvn_subr/svn_temp_serializer.c:282
>>> #4 0x00007ffff6403606 in svn_fs_fs__id_deserialize (
>>> buffer=<value optimized out>, id=0x7912b0)
>>> at subversion/libsvn_fs_fs/id.c:387
>>> #5 0x00007ffff63f4743 in svn_fs_fs__dag_deserialize (out=0x7fffffffd750,
>>> data=0x7912a8 "", data_len=<value optimized out>,
>>> pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1111
>> This is the first call to any de-serializer function
>> right after the raw data has been read cache.
>>
>> So, there is a chance that the data either got
>> corrupted by the cache itself or was garbage
>> even before that. Therefore, I added extensive
>> consistency checks in r1078185 to be able to
>> rule out the cache code itself.
>>
>> Please rebuild with -DDEBUG_CACHE_MEMBUFFER
>> and retry.
> Hmm, appears unchanged with this extra checking/debugging...
>
> John.
That is good news. Assuming that the consistency check
was actually enabled, we can rule out the cache for now.
From my perspective, this leaves at least two possibilities:
* compiler / optimizer issue
-> a look at the assembly output should clear that one quickly
* the data gets corrupted during serialization
-> serializer may need even more assertions()
-- Stefan^2.
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/2011 23:02, Stefan Fuhrmann wrote:
> On 04.03.2011 12:32, John Beranek wrote:
>> On 04/03/11 11:18, Philip Martin wrote:
>>> John Beranek<jo...@redux.org.uk> writes:
>>>
>>>> Oh, this is for a run of an installed copy of svnserve, as I don't
>>>> have a:
>>>>
>>>> subversion/tests/libsvn_client/.libs/lt-client-test
>>>>
>>>> only:
>>>>
>>>> subversion/tests/libsvn_client/client-test
>>>> [A wrapper script I can't run with gdb]
>>>>
>>>> subversion/tests/libsvn_client/.libs/client-test
>>>> [An executable that doesn't find its libraries]
>>> Building creates the libtool wrapper scipt client-test and the
>>> executable .libs/client-tests. The executable is one that will be
>>> installed and is linked to libraries in the install path.
>>>
>>> If you run the libtool wrapper script it creates a second, temporary
>>> executable .libs/lt-client-test. This is linked to libraries in the
>>> build directory. This is one you debug.
>> Oh, I _see_. :)
>>
>> #0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
>> #1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
>> #2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
>> #3 0x00007ffff5b88d0b in svn_temp_deserializer__resolve (
>> buffer=<value optimized out>, ptr=<value optimized out>)
>> at subversion/libsvn_subr/svn_temp_serializer.c:282
>> #4 0x00007ffff6403606 in svn_fs_fs__id_deserialize (
>> buffer=<value optimized out>, id=0x7912b0)
>> at subversion/libsvn_fs_fs/id.c:387
>> #5 0x00007ffff63f4743 in svn_fs_fs__dag_deserialize (out=0x7fffffffd750,
>> data=0x7912a8 "", data_len=<value optimized out>,
>> pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1111
> This is the first call to any de-serializer function
> right after the raw data has been read cache.
>
> So, there is a chance that the data either got
> corrupted by the cache itself or was garbage
> even before that. Therefore, I added extensive
> consistency checks in r1078185 to be able to
> rule out the cache code itself.
>
> Please rebuild with -DDEBUG_CACHE_MEMBUFFER
> and retry.
Hmm, appears unchanged with this extra checking/debugging...
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Stefan Fuhrmann <eq...@web.de>.
On 04.03.2011 12:32, John Beranek wrote:
> On 04/03/11 11:18, Philip Martin wrote:
>> John Beranek<jo...@redux.org.uk> writes:
>>
>>> Oh, this is for a run of an installed copy of svnserve, as I don't have a:
>>>
>>> subversion/tests/libsvn_client/.libs/lt-client-test
>>>
>>> only:
>>>
>>> subversion/tests/libsvn_client/client-test
>>> [A wrapper script I can't run with gdb]
>>>
>>> subversion/tests/libsvn_client/.libs/client-test
>>> [An executable that doesn't find its libraries]
>> Building creates the libtool wrapper scipt client-test and the
>> executable .libs/client-tests. The executable is one that will be
>> installed and is linked to libraries in the install path.
>>
>> If you run the libtool wrapper script it creates a second, temporary
>> executable .libs/lt-client-test. This is linked to libraries in the
>> build directory. This is one you debug.
> Oh, I _see_. :)
>
> #0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
> #1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
> #2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
> #3 0x00007ffff5b88d0b in svn_temp_deserializer__resolve (
> buffer=<value optimized out>, ptr=<value optimized out>)
> at subversion/libsvn_subr/svn_temp_serializer.c:282
> #4 0x00007ffff6403606 in svn_fs_fs__id_deserialize (
> buffer=<value optimized out>, id=0x7912b0)
> at subversion/libsvn_fs_fs/id.c:387
> #5 0x00007ffff63f4743 in svn_fs_fs__dag_deserialize (out=0x7fffffffd750,
> data=0x7912a8 "", data_len=<value optimized out>,
> pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1111
This is the first call to any de-serializer function
right after the raw data has been read cache.
So, there is a chance that the data either got
corrupted by the cache itself or was garbage
even before that. Therefore, I added extensive
consistency checks in r1078185 to be able to
rule out the cache code itself.
Please rebuild with -DDEBUG_CACHE_MEMBUFFER
and retry.
-- Stefan^2.
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 11:18, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> Oh, this is for a run of an installed copy of svnserve, as I don't have a:
>>
>> subversion/tests/libsvn_client/.libs/lt-client-test
>>
>> only:
>>
>> subversion/tests/libsvn_client/client-test
>> [A wrapper script I can't run with gdb]
>>
>> subversion/tests/libsvn_client/.libs/client-test
>> [An executable that doesn't find its libraries]
>
> Building creates the libtool wrapper scipt client-test and the
> executable .libs/client-tests. The executable is one that will be
> installed and is linked to libraries in the install path.
>
> If you run the libtool wrapper script it creates a second, temporary
> executable .libs/lt-client-test. This is linked to libraries in the
> build directory. This is one you debug.
Oh, I _see_. :)
#0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
#1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
#2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
#3 0x00007ffff5b88d0b in svn_temp_deserializer__resolve (
buffer=<value optimized out>, ptr=<value optimized out>)
at subversion/libsvn_subr/svn_temp_serializer.c:282
#4 0x00007ffff6403606 in svn_fs_fs__id_deserialize (
buffer=<value optimized out>, id=0x7912b0)
at subversion/libsvn_fs_fs/id.c:387
#5 0x00007ffff63f4743 in svn_fs_fs__dag_deserialize (out=0x7fffffffd750,
data=0x7912a8 "", data_len=<value optimized out>,
pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1111
#6 0x00007ffff5b61acb in svn_cache__get (value_p=<value optimized out>,
found=<value optimized out>, cache=0x763198, key=<value optimized out>,
pool=0x60d288) at subversion/libsvn_subr/cache.c:61
#7 0x00007ffff640663c in dag_node_cache_get (node_p=0x7fffffffd820,
root=0x763148, path=0x7912a0 "/iota", pool=0x60d288)
at subversion/libsvn_fs_fs/tree.c:179
#8 0x00007ffff6407f0e in open_path (parent_path_p=0x7fffffffd8c8,
root=0x763148, path=0x760e28 "iota", flags=0, txn_id=0x763190 "0-0",
pool=0x60d288) at subversion/libsvn_fs_fs/tree.c:641
#9 0x00007ffff64097ad in apply_textdelta (contents_p=0x7fffffffd998,
contents_baton_p=0x7fffffffd990, root=<value optimized out>,
---Type <return> to continue, or q <return> to quit---
path=0x760e28 "iota", base_checksum=0x0,
result_checksum=<value optimized out>, pool=0x60d288)
at subversion/libsvn_fs_fs/tree.c:2436
#10 fs_apply_textdelta (contents_p=0x7fffffffd998,
contents_baton_p=0x7fffffffd990, root=<value optimized out>,
path=0x760e28 "iota", base_checksum=0x0,
result_checksum=<value optimized out>, pool=0x60d288)
at subversion/libsvn_fs_fs/tree.c:2524
#11 0x00007ffff6ec9e3b in svn_fs_apply_textdelta
(contents_p=0x7fffffffd998,
contents_baton_p=0x7fffffffd990, root=0x763148, path=0x760e28 "iota",
base_checksum=<value optimized out>, result_checksum=0x0, pool=0x60d288)
at subversion/libsvn_fs/fs-loader.c:1176
#12 0x00007ffff7df82b9 in svn_test__set_file_contents (
root=<value optimized out>, path=<value optimized out>,
contents=0x7ffff7dfa516 "This is the file 'iota'.\n", pool=0x60d288)
at subversion/tests/svn_test_fs.c:279
#13 0x00007ffff7df8cad in svn_test__create_greek_tree_at
(txn_root=0x763148,
root_dir=0x760f08 "A/D/H/omega", pool=0x60d288)
at subversion/tests/svn_test_fs.c:646
#14 0x0000000000402f86 in test_patch (opts=<value optimized out>,
pool=0x60d288) at subversion/tests/libsvn_client/client-test.c:342
#15 0x00007ffff7df9af3 in do_test_num (
progname=0x7fffffffe297 "lt-client-test", test_num=3, msg_only=0,
opts=0x7fffffffddb0, header_msg=<value optimized out>, pool=0x60d288)
at subversion/tests/svn_test_main.c:274
#16 0x00007ffff7dfa24d in main (argc=1, argv=0x7fffffffdf08)
at subversion/tests/svn_test_main.c:543
#17 0x0000003786c1ee5d in __libc_start_main () from /lib64/libc.so.6
#18 0x0000000000401e59 in _start ()
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> Oh, this is for a run of an installed copy of svnserve, as I don't have a:
>
> subversion/tests/libsvn_client/.libs/lt-client-test
>
> only:
>
> subversion/tests/libsvn_client/client-test
> [A wrapper script I can't run with gdb]
>
> subversion/tests/libsvn_client/.libs/client-test
> [An executable that doesn't find its libraries]
Building creates the libtool wrapper scipt client-test and the
executable .libs/client-tests. The executable is one that will be
installed and is linked to libraries in the install path.
If you run the libtool wrapper script it creates a second, temporary
executable .libs/lt-client-test. This is linked to libraries in the
build directory. This is one you debug.
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 11:00, John Beranek wrote:
> On 03/03/11 23:48, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> Forgot to note, same assertion failure:
>>>
>>> START: client-test
>>> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
>>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>
>> A stack trace please:
>
> A small note here that confused me, I reconfigured with
> --enable-maintainer-mode and did a clean build, and the test failures
> and assertion went away. I was about to send a message apologising for
> not doing a clean build, but now I find if I turn off maintainer mode
> and do a clean build, I still get the failures.
>
> Here's a backtrace:
Oh, this is for a run of an installed copy of svnserve, as I don't have a:
subversion/tests/libsvn_client/.libs/lt-client-test
only:
subversion/tests/libsvn_client/client-test
[A wrapper script I can't run with gdb]
subversion/tests/libsvn_client/.libs/client-test
[An executable that doesn't find its libraries]
:/
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 14:02, John Beranek wrote:
> On 04/03/11 13:48, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>>> One thing you could try is identifying which revision causes the
>>>> problem. I'm guessing that r1072301 will PASS, it would be good to
>>>> know which is the first revision to FAIL.
>>>
>>> Hmm, no - r1072301 FAILs too.
>>
>> But it can't be crashing in svn_temp_deserializer__resolve because that
>> function doesn't exist in r1072301. That implies it is not the
>> serialisation code that is causing the problem.
>
> Argh, apologies - I've got myself confused between different WCs due to
> use of 'pushd'. Indeed r1072301 is a PASS!
Results of an overly conscientious 'bisect':
Start: 1072301
End: 1076903
0) 1072301 PASS
1) 1074601 FAIL
2) 1073451 FAIL
3) 1072876 FAIL
4) 1072588 FAIL
5) 1072444 FAIL
6) 1072372 FAIL
7) 1072336 FAIL
8) 1072318 no file changes
9) 1072309 no file changes
10) 1072302 no file changes, i.e. FAIL
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 13:48, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>>> One thing you could try is identifying which revision causes the
>>> problem. I'm guessing that r1072301 will PASS, it would be good to
>>> know which is the first revision to FAIL.
>>
>> Hmm, no - r1072301 FAILs too.
>
> But it can't be crashing in svn_temp_deserializer__resolve because that
> function doesn't exist in r1072301. That implies it is not the
> serialisation code that is causing the problem.
Argh, apologies - I've got myself confused between different WCs due to
use of 'pushd'. Indeed r1072301 is a PASS!
Sorry,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
>> One thing you could try is identifying which revision causes the
>> problem. I'm guessing that r1072301 will PASS, it would be good to
>> know which is the first revision to FAIL.
>
> Hmm, no - r1072301 FAILs too.
But it can't be crashing in svn_temp_deserializer__resolve because that
function doesn't exist in r1072301. That implies it is not the
serialisation code that is causing the problem.
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 13:09, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>>> That could be tricky. You are using 64-bit Fedora 14, what version of
>>> gcc and APR are you using? I can't reproduce it on my Debian/oldstable
>>> box. Fedora 14 is a cutting edge distribution, could it be a compiler
>>> bug?
>>
>> Fedora 14 is almost halfway to being obsolete, in Fedora's mind. ;)
>>
>> I've answered for gcc already, and:
>>
>> $ rpm -q apr
>> apr-1.3.9-3.fc13.x86_64
>
> One thing you could try is identifying which revision causes the
> problem. I'm guessing that r1072301 will PASS, it would be good to
> know which is the first revision to FAIL.
Hmm, no - r1072301 FAILs too.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
>> That could be tricky. You are using 64-bit Fedora 14, what version of
>> gcc and APR are you using? I can't reproduce it on my Debian/oldstable
>> box. Fedora 14 is a cutting edge distribution, could it be a compiler
>> bug?
>
> Fedora 14 is almost halfway to being obsolete, in Fedora's mind. ;)
>
> I've answered for gcc already, and:
>
> $ rpm -q apr
> apr-1.3.9-3.fc13.x86_64
One thing you could try is identifying which revision causes the
problem. I'm guessing that r1072301 will PASS, it would be good to
know which is the first revision to FAIL.
The crash might involve the caching's pointer twiddling code, so I
suppose it might be a signed integer overflow bug. Perhaps compiling
with EXTRA_CFLAGS='-O2 -fno-strict-overflow' would PASS?
It's difficult because I can't reproduce it.
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 12:45, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> On 04/03/11 11:52, Philip Martin wrote:
>>> John Beranek <jo...@redux.org.uk> writes:
>>>
>>>> Is there a recommended way to get -O0 into the compilation in Subversion
>>>> build land?
>>>
>>> You can "configure --enable-debug" or "make EXTRA_CFLAGS=-O0".
>>
>> OK, the test does indeed pass when the tree is built with just "make
>> EXTRA_CFLAGS=-O0".
>
> That could be tricky. You are using 64-bit Fedora 14, what version of
> gcc and APR are you using? I can't reproduce it on my Debian/oldstable
> box. Fedora 14 is a cutting edge distribution, could it be a compiler
> bug?
Fedora 14 is almost halfway to being obsolete, in Fedora's mind. ;)
I've answered for gcc already, and:
$ rpm -q apr
apr-1.3.9-3.fc13.x86_64
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 13:15, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> Oh, and my results with valgrind:
>>
>> PASS: lt-client-test 1: test svn_client__elide_mergeinfo_catalog
>> PASS: lt-client-test 2: test svn_client_args_to_target_array
>> PASS: lt-client-test 3: test svn_client_patch
>> ==4509== Use of uninitialised value of size 8
>> ==4509== at 0x30A020F957: ??? (in /usr/lib64/libapr-1.so.0.3.9)
>> ==4509== by 0x30A020FCAE: apr_hash_set (in /usr/lib64/libapr-1.so.0.3.9)
>> ==4509== by 0x50F34C4: svn_wc__db_drop_root (wc_db_pdh.c:595)
>
> r1077861 I think.
Thanks, that's tidied the Valgrind output on a -O0 build, but the
assertion is still evident on a EXTRA_CFLAGS='-O2 -fno-strict-overflow'
build.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> Oh, and my results with valgrind:
>
> PASS: lt-client-test 1: test svn_client__elide_mergeinfo_catalog
> PASS: lt-client-test 2: test svn_client_args_to_target_array
> PASS: lt-client-test 3: test svn_client_patch
> ==4509== Use of uninitialised value of size 8
> ==4509== at 0x30A020F957: ??? (in /usr/lib64/libapr-1.so.0.3.9)
> ==4509== by 0x30A020FCAE: apr_hash_set (in /usr/lib64/libapr-1.so.0.3.9)
> ==4509== by 0x50F34C4: svn_wc__db_drop_root (wc_db_pdh.c:595)
r1077861 I think.
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 12:45, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> On 04/03/11 11:52, Philip Martin wrote:
>>> John Beranek <jo...@redux.org.uk> writes:
>>>
>>>> Is there a recommended way to get -O0 into the compilation in Subversion
>>>> build land?
>>>
>>> You can "configure --enable-debug" or "make EXTRA_CFLAGS=-O0".
>>
>> OK, the test does indeed pass when the tree is built with just "make
>> EXTRA_CFLAGS=-O0".
>
> That could be tricky. You are using 64-bit Fedora 14, what version of
> gcc and APR are you using? I can't reproduce it on my Debian/oldstable
> box. Fedora 14 is a cutting edge distribution, could it be a compiler
> bug?
Oh, and my results with valgrind:
PASS: lt-client-test 1: test svn_client__elide_mergeinfo_catalog
PASS: lt-client-test 2: test svn_client_args_to_target_array
PASS: lt-client-test 3: test svn_client_patch
==4509== Use of uninitialised value of size 8
==4509== at 0x30A020F957: ??? (in /usr/lib64/libapr-1.so.0.3.9)
==4509== by 0x30A020FCAE: apr_hash_set (in /usr/lib64/libapr-1.so.0.3.9)
==4509== by 0x50F34C4: svn_wc__db_drop_root (wc_db_pdh.c:595)
==4509== by 0x509766A: integrate_nested_wc_as_copy (adm_ops.c:992)
==4509== by 0x5097CD7: svn_wc_add4 (adm_ops.c:1137)
==4509== by 0x50A1094: svn_wc_add3 (deprecated.c:813)
==4509== by 0x4033CB: test_wc_add_scenarios (client-test.c:486)
==4509== by 0x4C119B3: do_test_num (svn_test_main.c:274)
==4509== by 0x4C123F8: main (svn_test_main.c:543)
==4509==
==4509== Conditional jump or move depends on uninitialised value(s)
==4509== at 0x30A020F977: ??? (in /usr/lib64/libapr-1.so.0.3.9)
==4509== by 0x30A020FCAE: apr_hash_set (in /usr/lib64/libapr-1.so.0.3.9)
==4509== by 0x50F34C4: svn_wc__db_drop_root (wc_db_pdh.c:595)
==4509== by 0x509766A: integrate_nested_wc_as_copy (adm_ops.c:992)
==4509== by 0x5097CD7: svn_wc_add4 (adm_ops.c:1137)
==4509== by 0x50A1094: svn_wc_add3 (deprecated.c:813)
==4509== by 0x4033CB: test_wc_add_scenarios (client-test.c:486)
==4509== by 0x4C119B3: do_test_num (svn_test_main.c:274)
==4509== by 0x4C123F8: main (svn_test_main.c:543)
==4509==
PASS: lt-client-test 4: test svn_wc_add3 scenarios
PASS: lt-client-test 5: test a crash in svn_client_copy5
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> On 04/03/11 11:52, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> Is there a recommended way to get -O0 into the compilation in Subversion
>>> build land?
>>
>> You can "configure --enable-debug" or "make EXTRA_CFLAGS=-O0".
>
> OK, the test does indeed pass when the tree is built with just "make
> EXTRA_CFLAGS=-O0".
That could be tricky. You are using 64-bit Fedora 14, what version of
gcc and APR are you using? I can't reproduce it on my Debian/oldstable
box. Fedora 14 is a cutting edge distribution, could it be a compiler
bug?
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 12:21, John Beranek wrote:
> On 04/03/11 11:52, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> Is there a recommended way to get -O0 into the compilation in Subversion
>>> build land?
>>
>> You can "configure --enable-debug" or "make EXTRA_CFLAGS=-O0".
>
> OK, the test does indeed pass when the tree is built with just "make
> EXTRA_CFLAGS=-O0".
Assuming your next question:
$ gcc --version
gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 11:52, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> Is there a recommended way to get -O0 into the compilation in Subversion
>> build land?
>
> You can "configure --enable-debug" or "make EXTRA_CFLAGS=-O0".
OK, the test does indeed pass when the tree is built with just "make
EXTRA_CFLAGS=-O0".
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> Is there a recommended way to get -O0 into the compilation in Subversion
> build land?
You can "configure --enable-debug" or "make EXTRA_CFLAGS=-O0".
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 11:35, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> On 03/03/11 23:48, Philip Martin wrote:
>>> John Beranek <jo...@redux.org.uk> writes:
>>>
>>>> Forgot to note, same assertion failure:
>>>>
>>>> START: client-test
>>>> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
>>>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>>
>>> A stack trace please:
>>
>> A small note here that confused me, I reconfigured with
>> --enable-maintainer-mode and did a clean build, and the test failures
>> and assertion went away. I was about to send a message apologising for
>> not doing a clean build, but now I find if I turn off maintainer mode
>> and do a clean build, I still get the failures.
>>
>> Here's a backtrace:
>>
>> #0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
>> #1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
>> #2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
>> #3 0x00007ffff713dd0b in svn_temp_deserializer__resolve (
>> buffer=<value optimized out>, ptr=<value optimized out>)
>> at subversion/libsvn_subr/svn_temp_serializer.c:282
>
> This looks like an optimised build. Does this bug only happen when
> optimisation is enabled?
Is there a recommended way to get -O0 into the compilation in Subversion
build land?
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> On 03/03/11 23:48, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> Forgot to note, same assertion failure:
>>>
>>> START: client-test
>>> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
>>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>
>> A stack trace please:
>
> A small note here that confused me, I reconfigured with
> --enable-maintainer-mode and did a clean build, and the test failures
> and assertion went away. I was about to send a message apologising for
> not doing a clean build, but now I find if I turn off maintainer mode
> and do a clean build, I still get the failures.
>
> Here's a backtrace:
>
> #0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
> #1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
> #2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
> #3 0x00007ffff713dd0b in svn_temp_deserializer__resolve (
> buffer=<value optimized out>, ptr=<value optimized out>)
> at subversion/libsvn_subr/svn_temp_serializer.c:282
This looks like an optimised build. Does this bug only happen when
optimisation is enabled?
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/11 23:48, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> Forgot to note, same assertion failure:
>>
>> START: client-test
>> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>
> A stack trace please:
A small note here that confused me, I reconfigured with
--enable-maintainer-mode and did a clean build, and the test failures
and assertion went away. I was about to send a message apologising for
not doing a clean build, but now I find if I turn off maintainer mode
and do a clean build, I still get the failures.
Here's a backtrace:
#0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
#1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
#2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
#3 0x00007ffff713dd0b in svn_temp_deserializer__resolve (
buffer=<value optimized out>, ptr=<value optimized out>)
at subversion/libsvn_subr/svn_temp_serializer.c:282
#4 0x00007ffff79b8555 in deserialize_id_private (
buffer=<value optimized out>, id=0x7fffffffd778)
at subversion/libsvn_fs_fs/id.c:370
#5 svn_fs_fs__id_deserialize (buffer=<value optimized out>,
id=0x7fffffffd778)
at subversion/libsvn_fs_fs/id.c:397
#6 0x00007ffff79bb18a in svn_fs_fs__deserialize_id (out=0x7fffffffd8b8,
data=<value optimized out>, data_len=<value optimized out>,
pool=<value optimized out>)
at subversion/libsvn_fs_fs/temp_serializer.c:588
#7 0x00007ffff7115956 in membuffer_cache_get (value_p=0x7fffffffd8b8,
found=0x7fffffffd86c, cache_void=0x63cf30, key=<value optimized out>,
pool=0x778f08) at subversion/libsvn_subr/cache-membuffer.c:985
#8 svn_membuffer_cache_get (value_p=0x7fffffffd8b8, found=0x7fffffffd86c,
cache_void=0x63cf30, key=<value optimized out>, pool=0x778f08)
at subversion/libsvn_subr/cache-membuffer.c:1145
#9 0x00007ffff7116acb in svn_cache__get (value_p=<value optimized out>,
found=<value optimized out>, cache=0x63cf10, key=<value optimized out>,
pool=0x778f08) at subversion/libsvn_subr/cache.c:61
#10 0x00007ffff79b2b4d in svn_fs_fs__rev_get_root
(root_id_p=0x7fffffffd8b8,
fs=0x62e500, rev=1, pool=0x778f08) at
subversion/libsvn_fs_fs/fs_fs.c:2833
#11 0x00007ffff79a8b06 in svn_fs_fs__dag_revision_root
(node_p=0x7fffffffd8e8,
fs=0x62e500, rev=<value optimized out>, pool=0x778f08)
at subversion/libsvn_fs_fs/dag.c:605
#12 0x00007ffff79bcbc3 in svn_fs_fs__revision_root (root_p=0x7fffffffd9d8,
fs=0x62e500, rev=1, pool=0x778f08) at subversion/libsvn_fs_fs/tree.c:313
#13 0x000000000040d0b7 in get_dir (conn=0x626858, pool=0x772ed8,
params=<value optimized out>, baton=0x7fffffffdb40)
at subversion/svnserve/serve.c:1534
#14 0x00007ffff6ef83de in svn_ra_svn_handle_commands2 (conn=0x626858,
pool=<value optimized out>, commands=<value optimized out>,
baton=0x7fffffffdb40, error_on_disconnect=0)
at subversion/libsvn_ra_svn/marshal.c:1039
#15 0x000000000040e4ca in serve (conn=0x626858, params=<value optimized
out>,
pool=0x624848) at subversion/svnserve/serve.c:3228
#16 0x0000000000407730 in main (argc=<value optimized out>,
argv=<value optimized out>) at subversion/svnserve/main.c:933
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> Forgot to note, same assertion failure:
>
> START: client-test
> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
A stack trace please:
$ cd subversion/tests/libsvn_client
$ gdb .libs/lt-client-test
(gdb) r
SEGV
(gdb) bt
This might help, it fixes another valgrind warning but I don't really
understand it:
Index: subversion/libsvn_wc/wc_db_pdh.c
===================================================================
--- subversion/libsvn_wc/wc_db_pdh.c (revision 1076878)
+++ subversion/libsvn_wc/wc_db_pdh.c (working copy)
@@ -593,7 +593,7 @@
if (wcroot == root_wcroot)
apr_hash_set(db->dir_data,
- local_abspath, svn__apr_hash_index_klen(hi), NULL);
+ local_abspath, APR_HASH_KEY_STRING, NULL);
}
result = apr_pool_cleanup_run(db->state_pool, root_wcroot, close_wcroot);
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/2011 23:27, John Beranek wrote:
> On 03/03/2011 23:08, Philip Martin wrote:
>> Philip Martin <ph...@wandisco.com> writes:
>>
>>> There does appear to be a bug on trunk:
>>>
>>> $ valgrind --num-callers=20 -q ./.libs/lt-client-test 3
>>> ==26565== Conditional jump or move depends on uninitialised value(s)
>>> ==26565== at 0x4C2367A: bcmp (mc_replace_strmem.c:541)
>>
>> Fixed by r1076872.
>
> Tests are still failing for me, built r1076877. :(
Forgot to note, same assertion failure:
START: client-test
lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/2011 23:08, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
>> There does appear to be a bug on trunk:
>>
>> $ valgrind --num-callers=20 -q ./.libs/lt-client-test 3
>> ==26565== Conditional jump or move depends on uninitialised value(s)
>> ==26565== at 0x4C2367A: bcmp (mc_replace_strmem.c:541)
>
> Fixed by r1076872.
Tests are still failing for me, built r1076877. :(
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> There does appear to be a bug on trunk:
>
> $ valgrind --num-callers=20 -q ./.libs/lt-client-test 3
> ==26565== Conditional jump or move depends on uninitialised value(s)
> ==26565== at 0x4C2367A: bcmp (mc_replace_strmem.c:541)
Fixed by r1076872.
--
Philip
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> On 03/03/2011 20:01, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>> On 03/03/2011 18:30, Philip Martin wrote:
>>>> John Beranek <jo...@redux.org.uk> writes:
>>>>
>>>>>
>>>>> Am I doing something stupid, or is there some breakage on the trunk?
>>>>
>>
>> That looks like a problem with your build, tests.log might help but you
>> probably need to build with debug info and debug one of the failing
>> tests with gdb.
>
> Surprise surprise - the same assertion I get in svnserve/mod_dav_svn:
>
> START: client-test
> lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
There does appear to be a bug on trunk:
$ valgrind --num-callers=20 -q ./.libs/lt-client-test 3
==26565== Conditional jump or move depends on uninitialised value(s)
==26565== at 0x4C2367A: bcmp (mc_replace_strmem.c:541)
==26565== by 0x6270B78: find_entry (in /usr/lib/libapr-1.so.0.4.2)
==26565== by 0x6270E32: apr_hash_get (in /usr/lib/libapr-1.so.0.4.2)
==26565== by 0x55835DA: get_revision_info (reporter.c:462)
==26565== by 0x558387C: delta_proplists (reporter.c:527)
==26565== by 0x5585258: delta_dirs (reporter.c:1023)
==26565== by 0x5584DA1: update_entry (reporter.c:908)
==26565== by 0x5585BB6: delta_dirs (reporter.c:1187)
==26565== by 0x5584DA1: update_entry (reporter.c:908)
==26565== by 0x5585BB6: delta_dirs (reporter.c:1187)
==26565== by 0x5584DA1: update_entry (reporter.c:908)
==26565== by 0x5585BB6: delta_dirs (reporter.c:1187)
==26565== by 0x5586120: drive (reporter.c:1251)
==26565== by 0x55865F6: finish_report (reporter.c:1318)
==26565== by 0x5586A4F: svn_repos_finish_report (reporter.c:1408)
==26565== by 0x6E42822: reporter_finish_report (ra_plugin.c:214)
==26565== by 0x52C3726: svn_wc_crawl_revisions5 (adm_crawler.c:983)
==26565== by 0x509B5F6: update_internal (update.c:231)
==26565== by 0x509BBDD: svn_client__update_internal (update.c:369)
==26565== by 0x5044B43: svn_client__checkout_internal (checkout.c:216)
==26565==
==26565== Conditional jump or move depends on uninitialised value(s)
==26565== at 0x6270B7B: find_entry (in /usr/lib/libapr-1.so.0.4.2)
==26565== by 0x6270E32: apr_hash_get (in /usr/lib/libapr-1.so.0.4.2)
==26565== by 0x55835DA: get_revision_info (reporter.c:462)
==26565== by 0x558387C: delta_proplists (reporter.c:527)
==26565== by 0x5585258: delta_dirs (reporter.c:1023)
==26565== by 0x5584DA1: update_entry (reporter.c:908)
==26565== by 0x5585BB6: delta_dirs (reporter.c:1187)
==26565== by 0x5584DA1: update_entry (reporter.c:908)
==26565== by 0x5585BB6: delta_dirs (reporter.c:1187)
==26565== by 0x5584DA1: update_entry (reporter.c:908)
==26565== by 0x5585BB6: delta_dirs (reporter.c:1187)
==26565== by 0x5586120: drive (reporter.c:1251)
==26565== by 0x55865F6: finish_report (reporter.c:1318)
==26565== by 0x5586A4F: svn_repos_finish_report (reporter.c:1408)
==26565== by 0x6E42822: reporter_finish_report (ra_plugin.c:214)
==26565== by 0x52C3726: svn_wc_crawl_revisions5 (adm_crawler.c:983)
==26565== by 0x509B5F6: update_internal (update.c:231)
==26565== by 0x509BBDD: svn_client__update_internal (update.c:369)
==26565== by 0x5044B43: svn_client__checkout_internal (checkout.c:216)
==26565== by 0x5044C99: svn_client_checkout3 (checkout.c:255)
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/2011 20:01, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> On 03/03/2011 18:30, Philip Martin wrote:
>>> John Beranek <jo...@redux.org.uk> writes:
>>>
>>>>
>>>> Am I doing something stupid, or is there some breakage on the trunk?
>>>
>
> That looks like a problem with your build, tests.log might help but you
> probably need to build with debug info and debug one of the failing
> tests with gdb.
Surprise surprise - the same assertion I get in svnserve/mod_dav_svn:
START: client-test
lt-client-test: subversion/libsvn_subr/svn_temp_serializer.c:282:
svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> On 03/03/2011 18:30, Philip Martin wrote:
>> John Beranek <jo...@redux.org.uk> writes:
>>
>>>
>>> Am I doing something stupid, or is there some breakage on the trunk?
>>
>> Some, but not that.
>>
>> http://subversion.apache.org/buildbot
>>
>> Do the regression tests pass on your machine?
>
> Not an overwhelming success:
>
> $ make check
> Running tests in auth-test [1/88].............................success
> Running tests in cache-test [2/88]............................success
> Running tests in checksum-test [3/88].........................success
> Running tests in client-test [4/88]...........................FAILURE
> Running tests in compat-test [5/88]...........................success
> Running tests in config-test [6/88]...........................success
> Running tests in db-test [7/88]...............................success
> Running tests in diff-diff3-test [8/88].......................success
> Running tests in dirent_uri-test [9/88].......................success
> Running tests in entries-compat-test [10/88]..................success
> Running tests in eol-test [11/88].............................success
> Running tests in error-test [12/88]...........................success
> Running tests in fs-pack-test [13/88].........................FAILURE
> Running tests in fs-test [14/88]..............................FAILURE
> Running tests in hashdump-test [15/88]........................success
> Running tests in locks-test [16/88]...........................FAILURE
> Running tests in mergeinfo-test [17/88].......................success
> Running tests in op-depth-test [18/88]........................FAILURE
> Running tests in opt-test [19/88].............................success
> Running tests in parse-diff-test [20/88]......................success
> Running tests in path-test [21/88]............................success
> Running tests in pristine-store-test [22/88]..................FAILURE
> Running tests in ra-local-test [23/88]........................success
> Running tests in random-test [24/88]..........................success
> Running tests in repos-test [25/88]...........................FAILURE
> Running tests in revision-test [26/88]........................success
> Running tests in skel-test [27/88]............................success
> Running tests in stream-test [28/88]..........................success
> Running tests in string-test [29/88]..........................success
> Running tests in subst_translate-test [30/88].................success
> Running tests in target-test [31/88]..........................success
> Running tests in time-test [32/88]............................success
> Running tests in translate-test [33/88].......................success
> Running tests in tree-conflict-data-test [34/88]..............success
> Running tests in utf-test [35/88].............................success
> Running tests in window-test [36/88]..........................success
> Running tests in authz_tests.py [37/88]make: *** [check] Error 1
That looks like a problem with your build, tests.log might help but you
probably need to build with debug info and debug one of the failing
tests with gdb.
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 03/03/2011 18:30, Philip Martin wrote:
> John Beranek <jo...@redux.org.uk> writes:
>
>> This afternoon, I checked out the trunk from Subversion in order to
>> build a dev system running 1.7.
>>
>> I updated a sandbox I had lying around, made it 'extraclean', built and
>> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
>> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
>> Subversion.
>>
>> All of this was done on a Fedora 14 x86_64 system. What I got for my
>> troubles was assertion failures when trying a commit with either
>> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
>>
>> subversion/libsvn_subr/svn_temp_serializer.c:282:
>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>
>> Am I doing something stupid, or is there some breakage on the trunk?
>
> Some, but not that.
>
> http://subversion.apache.org/buildbot
>
> Do the regression tests pass on your machine?
Not an overwhelming success:
$ make check
Running tests in auth-test [1/88].............................success
Running tests in cache-test [2/88]............................success
Running tests in checksum-test [3/88].........................success
Running tests in client-test [4/88]...........................FAILURE
Running tests in compat-test [5/88]...........................success
Running tests in config-test [6/88]...........................success
Running tests in db-test [7/88]...............................success
Running tests in diff-diff3-test [8/88].......................success
Running tests in dirent_uri-test [9/88].......................success
Running tests in entries-compat-test [10/88]..................success
Running tests in eol-test [11/88].............................success
Running tests in error-test [12/88]...........................success
Running tests in fs-pack-test [13/88].........................FAILURE
Running tests in fs-test [14/88]..............................FAILURE
Running tests in hashdump-test [15/88]........................success
Running tests in locks-test [16/88]...........................FAILURE
Running tests in mergeinfo-test [17/88].......................success
Running tests in op-depth-test [18/88]........................FAILURE
Running tests in opt-test [19/88].............................success
Running tests in parse-diff-test [20/88]......................success
Running tests in path-test [21/88]............................success
Running tests in pristine-store-test [22/88]..................FAILURE
Running tests in ra-local-test [23/88]........................success
Running tests in random-test [24/88]..........................success
Running tests in repos-test [25/88]...........................FAILURE
Running tests in revision-test [26/88]........................success
Running tests in skel-test [27/88]............................success
Running tests in stream-test [28/88]..........................success
Running tests in string-test [29/88]..........................success
Running tests in subst_translate-test [30/88].................success
Running tests in target-test [31/88]..........................success
Running tests in time-test [32/88]............................success
Running tests in translate-test [33/88].......................success
Running tests in tree-conflict-data-test [34/88]..............success
Running tests in utf-test [35/88].............................success
Running tests in window-test [36/88]..........................success
Running tests in authz_tests.py [37/88]make: *** [check] Error 1
I had a thought on the way home it could be something to do with shared
library conflicts, but that doesn't seem to be a problem:
$ ldd /usr/local/subversion-1.7/bin/svnserve
linux-vdso.so.1 => (0x00007fff1edff000)
libsvn_repos-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_repos-1.so.0 (0x00007f5df6f63000)
libsvn_fs-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_fs-1.so.0 (0x00007f5df6d5b000)
libsvn_fs_fs-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_fs_fs-1.so.0 (0x00007f5df6b31000)
libsvn_fs_base-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_fs_base-1.so.0 (0x00007f5df6900000)
libsvn_fs_util-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_fs_util-1.so.0 (0x00007f5df66fd000)
libsvn_delta-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_delta-1.so.0 (0x00007f5df64f0000)
libsvn_subr-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_subr-1.so.0 (0x00007f5df6291000)
libsvn_ra_svn-1.so.0 =>
/usr/local/subversion-1.7/lib/libsvn_ra_svn-1.so.0 (0x00007f5df6078000)
libz.so.1 => /lib64/libz.so.1 (0x0000003788000000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x000000379e600000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0
(0x0000003792400000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003797600000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x000000378ac00000)
libdb-4.8.so => /lib64/libdb-4.8.so (0x0000003794800000)
libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x000000378e400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003787800000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x000000379d200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003786c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003787000000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x000000378c400000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f5df5ddf000)
/lib64/ld-linux-x86-64.so.2 (0x0000003786800000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x000000378a000000)
Cheers,
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Philip Martin <ph...@wandisco.com>.
John Beranek <jo...@redux.org.uk> writes:
> This afternoon, I checked out the trunk from Subversion in order to
> build a dev system running 1.7.
>
> I updated a sandbox I had lying around, made it 'extraclean', built and
> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
> Subversion.
>
> All of this was done on a Fedora 14 x86_64 system. What I got for my
> troubles was assertion failures when trying a commit with either
> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
>
> subversion/libsvn_subr/svn_temp_serializer.c:282:
> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>
> Am I doing something stupid, or is there some breakage on the trunk?
Some, but not that.
http://subversion.apache.org/buildbot
Do the regression tests pass on your machine?
--
Philip
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/2011 15:07, Daniel Shahaf wrote:
> John Beranek wrote on Fri, Mar 04, 2011 at 14:49:48 +0000:
>> On 04/03/11 14:44, Daniel Shahaf wrote:
>>> John Beranek wrote on Thu, Mar 03, 2011 at 17:54:04 +0000:
>>>> Hi,
>>>>
>>>> This afternoon, I checked out the trunk from Subversion in order to
>>>> build a dev system running 1.7.
>>>>
>>>> I updated a sandbox I had lying around, made it 'extraclean', built and
>>>> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
>>>> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
>>>> Subversion.
>>>>
>>>> All of this was done on a Fedora 14 x86_64 system. What I got for my
>>>> troubles was assertion failures when trying a commit with either
>>>> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
>>>>
>>>> subversion/libsvn_subr/svn_temp_serializer.c:282:
>>>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>>>
>>>
>>> What are *PTR and BUFFER at that point?
>>
>> Both are optimised out:
>
> Okay. Perhaps you could try to localize the bug --- whether it's in the
> temp_serializer framework itself, or in one of its callers? For
> example, if you make dag_node_cache_get() always return NULL, do you
> still get assertions from other users of the cache?
Yes, still more assertions with the change you suggest above:
#0 0x0000003786c330c5 in raise () from /lib64/libc.so.6
#1 0x0000003786c34a76 in abort () from /lib64/libc.so.6
#2 0x0000003786c2b905 in __assert_fail () from /lib64/libc.so.6
#3 0x00007ffff5b8850b in svn_temp_deserializer__resolve (
buffer=<value optimized out>, ptr=<value optimized out>)
at subversion/libsvn_subr/svn_temp_serializer.c:282
#4 0x00007ffff6403625 in deserialize_id_private (
buffer=<value optimized out>, id=0x7fffffffdc08)
at subversion/libsvn_fs_fs/id.c:370
#5 svn_fs_fs__id_deserialize (buffer=<value optimized out>,
id=0x7fffffffdc08)
at subversion/libsvn_fs_fs/id.c:397
#6 0x00007ffff640625a in svn_fs_fs__deserialize_id (out=0x7fffffffdd48,
data=<value optimized out>, data_len=<value optimized out>,
pool=<value optimized out>)
at subversion/libsvn_fs_fs/temp_serializer.c:588
#7 0x00007ffff5b60716 in membuffer_cache_get (value_p=0x7fffffffdd48,
found=0x7fffffffdcfc, cache_void=0x648020, key=<value optimized out>,
pool=0x7fdbd8) at subversion/libsvn_subr/cache-membuffer.c:987
#8 svn_membuffer_cache_get (value_p=0x7fffffffdd48, found=0x7fffffffdcfc,
cache_void=0x648020, key=<value optimized out>, pool=0x7fdbd8)
at subversion/libsvn_subr/cache-membuffer.c:1140
#9 0x00007ffff5b6188b in svn_cache__get (value_p=<value optimized out>,
found=<value optimized out>, cache=0x648000, key=<value optimized out>,
pool=0x7fdbd8) at subversion/libsvn_subr/cache.c:61
#10 0x00007ffff63fdc1d in svn_fs_fs__rev_get_root (root_id_p=0x7fffffffdd48,
fs=0x61a700, rev=0, pool=0x7fdbd8) at
subversion/libsvn_fs_fs/fs_fs.c:2833
#11 0x00007ffff63f3bc6 in svn_fs_fs__dag_revision_root
(node_p=0x7fffffffdd78,
fs=0x61a700, rev=<value optimized out>, pool=0x7fdbd8)
at subversion/libsvn_fs_fs/dag.c:605
#12 0x00007ffff6407bd3 in svn_fs_fs__revision_root (root_p=0x7fffffffde00,
fs=0x61a700, rev=0, pool=0x7fdbd8) at subversion/libsvn_fs_fs/tree.c:315
#13 0x00007ffff640b1d3 in svn_fs_fs__commit_txn (conflict_p=0x0,
new_rev=0x7fffffffdfc0, txn=0x75adb8, pool=<value optimized out>)
at subversion/libsvn_fs_fs/tree.c:1680
#14 0x00007ffff72e4b56 in svn_repos_fs_commit_txn (conflict_p=0x0,
repos=0x60e810, new_rev=0x7fffffffdfc0, txn=0x75adb8, pool=0x60d288)
at subversion/libsvn_repos/fs-wrap.c:59
#15 0x0000000000403021 in test_patch (opts=<value optimized out>,
pool=0x60d288) at subversion/tests/libsvn_client/client-test.c:343
#16 0x00007ffff7df9b23 in do_test_num (
progname=0x7fffffffe602 "lt-client-test", test_num=3, msg_only=0,
opts=0x7fffffffe1c0, header_msg=<value optimized out>, pool=0x60d288)
at subversion/tests/svn_test_main.c:274
#17 0x00007ffff7dfa27d in main (argc=1, argv=0x7fffffffe318)
at subversion/tests/svn_test_main.c:543
#18 0x0000003786c1ee5d in __libc_start_main () from /lib64/libc.so.6
#19 0x0000000000401ec9 in _start ()
>
> Daniel
> (shooting in the dark)
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
John Beranek wrote on Fri, Mar 04, 2011 at 14:49:48 +0000:
> On 04/03/11 14:44, Daniel Shahaf wrote:
> > John Beranek wrote on Thu, Mar 03, 2011 at 17:54:04 +0000:
> >> Hi,
> >>
> >> This afternoon, I checked out the trunk from Subversion in order to
> >> build a dev system running 1.7.
> >>
> >> I updated a sandbox I had lying around, made it 'extraclean', built and
> >> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
> >> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
> >> Subversion.
> >>
> >> All of this was done on a Fedora 14 x86_64 system. What I got for my
> >> troubles was assertion failures when trying a commit with either
> >> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
> >>
> >> subversion/libsvn_subr/svn_temp_serializer.c:282:
> >> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
> >>
> >
> > What are *PTR and BUFFER at that point?
>
> Both are optimised out:
Okay. Perhaps you could try to localize the bug --- whether it's in the
temp_serializer framework itself, or in one of its callers? For
example, if you make dag_node_cache_get() always return NULL, do you
still get assertions from other users of the cache?
Daniel
(shooting in the dark)
Re: Breakage on trunk?
Posted by John Beranek <jo...@redux.org.uk>.
On 04/03/11 14:44, Daniel Shahaf wrote:
> John Beranek wrote on Thu, Mar 03, 2011 at 17:54:04 +0000:
>> Hi,
>>
>> This afternoon, I checked out the trunk from Subversion in order to
>> build a dev system running 1.7.
>>
>> I updated a sandbox I had lying around, made it 'extraclean', built and
>> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
>> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
>> Subversion.
>>
>> All of this was done on a Fedora 14 x86_64 system. What I got for my
>> troubles was assertion failures when trying a commit with either
>> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
>>
>> subversion/libsvn_subr/svn_temp_serializer.c:282:
>> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>>
>
> What are *PTR and BUFFER at that point?
Both are optimised out:
#3 0x00007ffff5b8850b in svn_temp_deserializer__resolve (
buffer=<value optimized out>, ptr=<value optimized out>)
at subversion/libsvn_subr/svn_temp_serializer.c:282
#4 0x00007ffff6403636 in svn_fs_fs__id_deserialize (
buffer=<value optimized out>, id=0x7912b0)
at subversion/libsvn_fs_fs/id.c:387
#5 0x00007ffff63f4763 in svn_fs_fs__dag_deserialize (out=0x7fffffffd740,
data=0x7912a8 "", data_len=<value optimized out>,
pool=<value optimized out>) at subversion/libsvn_fs_fs/dag.c:1111
#6 0x00007ffff5b6188b in svn_cache__get (value_p=<value optimized out>,
found=<value optimized out>, cache=0x763198, key=<value optimized out>,
pool=0x60d288) at subversion/libsvn_subr/cache.c:61
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
Re: Breakage on trunk?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
John Beranek wrote on Thu, Mar 03, 2011 at 17:54:04 +0000:
> Hi,
>
> This afternoon, I checked out the trunk from Subversion in order to
> build a dev system running 1.7.
>
> I updated a sandbox I had lying around, made it 'extraclean', built and
> installed serf 0.7.1, ran autogen.sh, ran configure (with --prefix
> /usr/local/subversion-1.7 --with-serf=/usr/local), built and installed
> Subversion.
>
> All of this was done on a Fedora 14 x86_64 system. What I got for my
> troubles was assertion failures when trying a commit with either
> Apache+mod_dav_svn or with svnserve. The assertion failure in question is:
>
> subversion/libsvn_subr/svn_temp_serializer.c:282:
> svn_temp_deserializer__resolve: Assertion `*ptr > buffer' failed.
>
What are *PTR and BUFFER at that point?
> Am I doing something stupid, or is there some breakage on the trunk?
>
> Cheers,
>
> John.
>
> --
> John Beranek To generalise is to be an idiot.
> http://redux.org.uk/ -- William Blake