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.
Cheers,
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2363003
Received on 2009-06-17 23:50:09 CEST