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<john_at_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.
Received on 2011-03-05 11:34:52 CET