On Jun 17, 2009, at 4:49 PM, David James wrote:
> 2009/6/16 Роман Донченко <DXDragon_at_yandex.ru>:
>> Greetings,
>>
>> This is what I get when running
>> subversion/bindings/swig/python/tests/client.py:
>>
>> ~
>> F............
>> =
>> =====================================================================
>> FAIL: Test playing with C batons
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "client.py", line 54, in testBatonPlay
>> str(self.client_ctx.auth_baton))
>> AssertionError: "<libsvn.core.svn_auth_baton_t; proxy of <Swig
>> Object of
>> type 's
>> vn_auth_baton_t *' at 0x01561C20> >" !=
>> "<libsvn.core.svn_auth_baton_t;
>> proxy of
>> <Swig Object of type 'svn_auth_baton_t *' at 0x01561C00> >"
>>
>> ----------------------------------------------------------------------
>> Ran 13 tests in 27.438s
>>
>> FAILED (failures=1)
>> ~
>>
>> This comes from the following test:
>>
>> self.client_ctx.log_msg_baton2 = self.client_ctx.auth_baton
>> self.assertEquals(str(self.client_ctx.log_msg_baton2),
>> str(self.client_ctx.auth_baton))
>>
>> Looks harmless, but surprisingly the string representation of SWIG
>> structure turned out to vary over time in unpredictable ways!
>>
>> ~
>> ActivePython 2.6.2.2 (ActiveState Software Inc.) based on
>> Python 2.6.2 (r262:71600, Apr 21 2009, 15:05:37) [MSC v.1500 32 bit
>> (Intel)] on
>> win32
>> Type "help", "copyright", "credits" or "license" for more
>> information.
>>>>> from svn.core import *
>>>>> from svn.client import *
>>>>> ab = svn_auth_open([svn_auth_get_simple_provider()])
>>>>> ab
>> <libsvn.core.svn_auth_baton_t; proxy of <Swig Object of type
>> 'svn_auth_baton_t *
>> ' at 0x0145A9C0> >
>>>>> ab
>> <libsvn.core.svn_auth_baton_t; proxy of <Swig Object of type
>> 'svn_auth_baton_t *
>> ' at 0x0145A960> >
>>>>> ab
>> <libsvn.core.svn_auth_baton_t; proxy of <Swig Object of type
>> 'svn_auth_baton_t *
>> ' at 0x0145A9E0> >
>>>>> ab
>> <libsvn.core.svn_auth_baton_t; proxy of <Swig Object of type
>> 'svn_auth_baton_t *
>> ' at 0x0145A9C0> >
>>>>> ab
>> <libsvn.core.svn_auth_baton_t; proxy of <Swig Object of type
>> 'svn_auth_baton_t *
>> ' at 0x0145A960> >
>>>>> ab
>> <libsvn.core.svn_auth_baton_t; proxy of <Swig Object of type
>> 'svn_auth_baton_t *
>> ' at 0x0145A9E0> >
>> ~
>>
>> I wasn't able to trace the reason for this, but it happens for all
>> SWIG
>> structures. Thus, I'm proposing to remove the tests causing this
>> because
>> a) there appears to be no easy way of fixing this (AFAIK, SWIG
>> doesn't
>> guarantee anything about the string representation of structures)
>> and b)
>> those tests are kind of pointless anyway, comparing a copy to the
>> original. See attached patch. It also removes the
>> "self.client_ctx.log_msg_baton2 == None" test because that is already
>> tested by setUp().
>>
>> I'm not explicitly marking this as a patch because I'm not sure if
>> SWIG is
>> really supposed to behave this way. Attempts to reproduce are
>> welcome. 8=]
>> The above was generated using SWIG 1.3.39, trunk Subversion, and
>> you can
>> see the rest in Python's banner above.
>
> Hi Roman,
>
> I agree with your analysis. The purpose of the test was to test the
> SWIG bindings' reference counting logic. We want to ensure that when
> we copy an object into a structure, the original object remains alive
> and well. I consider SWIG's new strange stringification behavior to be
> a bug, but we may well have to live with it and remove or update the
> test.
>
> An alternative way to do the same test would be to use weak
> references. See the test_pool function in pool.py. In this case, we
> would need to do the following:
> 1) Add a weak reference to our baton
> 2) Add our baton to the client context
> 3) Delete all references to our baton except the reference in the
> client context
> 4) Verify that our baton is still around via the weak reference
> 5) Delete the client context
> 6) Verify the baton is deleted
>
> In any case, it's more important to get the test suite working than to
> have complete coverage, so I think it would be best to commit your
> patch. I'll commit this patch soon if nobody has any other
> suggestions.
Generally, I don't think the answer to failing tests is "fix the
test", but rather "fix the bug causing the failure". In this case,
though, it appears from your above statement that the bug is in SWIG,
not in Subversion, so it would make sense to temporarily disable the
test, until the bug in SWIG is fixed.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363132
Received on 2009-06-18 12:46:59 CEST