You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Роман Донченко <DX...@yandex.ru> on 2009/06/16 22:44:24 UTC
testBatonPlay in the Python bindings testsuite fails
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.
Cheers,
Roman.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2362640
Re: testBatonPlay in the Python bindings testsuite fails
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Jun 17, 2009, at 4:49 PM, David James wrote:
> 2009/6/16 Роман Донченко <DX...@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
Re: testBatonPlay in the Python bindings testsuite fails
Posted by Роман Донченко <DX...@yandex.ru>.
David James <ja...@gmail.com> писал(а) в своём письме Sat, 20 Jun 2009
23:50:22 +0400:
> 2009/6/17 David James <ja...@gmail.com>:
>> 2009/6/16 Роман Донченко <DX...@yandex.ru>:
>>> ...
>>> ~
>>> 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)
>>> ~
>>> ...
>>
>> ...
>> 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
>> ...
>
> Hi Roman,
>
> I went ahead and reimplemented the test using weak references in
> r38118. This avoids any dependency on how SWIG stringifies objects.
>
> Roman, could you test this new version of the test with your version
> of SWIG and let me know if it fixes the problem?
Yep, all tests in client.py pass now.
Roman.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363827
Re: testBatonPlay in the Python bindings testsuite fails
Posted by David James <ja...@gmail.com>.
2009/6/17 David James <ja...@gmail.com>:
> 2009/6/16 Роман Донченко <DX...@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.
Hi Roman,
I went ahead and reimplemented the test using weak references in
r38118. This avoids any dependency on how SWIG stringifies objects.
Roman, could you test this new version of the test with your version
of SWIG and let me know if it fixes the problem?
Cheers,
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363802
Re: testBatonPlay in the Python bindings testsuite fails
Posted by David James <ja...@gmail.com>.
2009/6/16 Роман Донченко <DX...@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.
Cheers,
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363003