You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Christian Boos <cb...@neuf.fr> on 2006/12/19 15:38:38 UTC
Bug with http: URLs with functions from the client module in the
Python bindings
Hi,
I think I've found a bug in the client module of the Python bindings, in
1.4.x.
Erik Huelsmann asked me to follow-up in this mailing list.
Alternatively, it can well be a misuse of the API, in which case I'd be
glad to get a few pointers to the relevant documentation (well, besides
the doxygen documentation for the C API and the Python binding tests).
Erik Huelsmann wrote:
> ...
>> (about a script testing client.blame2)
>> This seems to work for file: and svn: URLs only, at least for me with
>> Subversion 1.4.0 on windows, as I got crashes in _client.dll when trying
>> out http: URLs...
>>
>
> Could you send a reproduction recipe for that to
> dev@subversion.tigris.org please? We'll want to fix that in 1.4.4 as
> soon as it comes out.
>
Simply use the provided blame.py script with an http: URL, e.g.
python C:/TMP/blame.py http://svn.edgewall.org/repos/trac/trunk/README
Stack trace:
> _client.dll!00fb5c9d()
_client.dll!00f885e1()
_client.dll!00f876ad()
_client.dll!00f7cd2e()
_client.dll!00f7ded6()
python24.dll!1e02b1e1()
_client.dll!00f75710()
python24.dll!1e07f46b()
libsvn_swig_py-1.dll!00d61a12()
_client.dll!00f75e7d()
_client.dll!00f5dbdf()
python24.dll!1e079c47()
...
Actually, the URL doesn't even need to be valid to trigger the crash:
python C:/TMP/blame.py http://xxx
Stack trace:
> _client.dll!00fb5c9d()
...
The problem is not specific to the client.blame2 function, as I get the
same stacktrace with client.svn_client_info.
I've just checked with the 1.4.2 bindings for Python 2.4, as available
from tigris.org and the bug is there as well.
Sorry for not giving more context with the stacktrace, but putting the
.pdb next to the dlls didn't help for some reason.
Thanks for your time!
-- Christian
Re: Bug with http: URLs with functions from the client module in the
Python bindings
Posted by Christian Boos <cb...@neuf.fr>.
David James wrote:
>> > # use blame3, and for that, find a way to get a
>> svn_diff_file_options_t
>> > # instance
>> >
>>
>> ... as the only reference I found to svn_diff_file_options_t in the
>> python bindings was in the docstring of svn_client_blame3.
>>
>> E.g. any hint about this one?
>
>
> Currently, svn_diff_file_options_t is not wrapped, but you could
> probably fix this easily by adding an %include svn_diff_h.swg line to
> swig/core.i in the Python bindings. The Perl bindings already include
> svn_diff_h.swg, but the Python bindings do not.
>
> Once you've added %include svn_diff_h.swg to core.i, you should be
> able to create a svn_diff_file_options_t object by calling
> svn.core.svn_diff_file_create()
Well, it's more about a feature we could use in Trac or not. So we can
tell our users to upgrade to e.g. Subversion 1.4.4 but probably not to
patch their swig/core.i file (ok, we could say that and then hide
quickly...)
The point of using blame3 instead of blame2 is that we have our own
heuristic to decide whether a file is binary or not, so we could decide
to force the blame or not (setting ignore_mime_type to True, as blame2
sets it to False). But that's probably a very minor limitation, so it's
not that important.
Thanks again!
-- Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug with http: URLs with functions from the client module in the Python bindings
Posted by David James <ja...@cs.toronto.edu>.
On 12/20/06, Christian Boos <cb...@neuf.fr> wrote:
> Thanks a lot, the fixed script works for me as well!
Great, I'm glad to help!
> > Here's how to setup the authentication providers. I borrowed this
> > example from
> > http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn_export_empty_files.py
> >
>
> Thanks for the pointer, I overlooked this one.
>
> That's great news, looks like the access to remote repositories through
> the python bindings is now working. So expect blame support, and
> possibly access to remote repositories in Trac 0.11 ;)
> Is there a particular help channel of choice where I could ask for more
> help on the Python bindings, would that be needed (here, on
> Subversion-users, directly to djames?)
If you need help on the Python bindings, send your questions to the
dev@ or users@ lists as you consider appropriate, and CC me.
> E.g. any hint about this one?
> > # use blame3, and for that, find a way to get a svn_diff_file_options_t
> > # instance
> >
>
> ... as the only reference I found to svn_diff_file_options_t in the
> python bindings was in the docstring of svn_client_blame3.
Currently, svn_diff_file_options_t is not wrapped, but you could
probably fix this easily by adding an %include svn_diff_h.swg line to
swig/core.i in the Python bindings. The Perl bindings already include
svn_diff_h.swg, but the Python bindings do not.
Once you've added %include svn_diff_h.swg to core.i, you should be
able to create a svn_diff_file_options_t object by calling
svn.core.svn_diff_file_create()
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug with http: URLs with functions from the client module in
the Python bindings
Posted by Christian Boos <cb...@neuf.fr>.
Hi David,
Thanks a lot, the fixed script works for me as well!
David James wrote:
> ...
> We should probably also patch the client.py test suite for the Python
> bindings to correctly setup the auth_baton, so that people don't get
> bit when they copy and paste examples from the test suite.
Right, this is where I got the code from ;)
> Here's how to setup the authentication providers. I borrowed this
> example from
> http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn_export_empty_files.py
>
Thanks for the pointer, I overlooked this one.
That's great news, looks like the access to remote repositories through
the python bindings is now working. So expect blame support, and
possibly access to remote repositories in Trac 0.11 ;)
Is there a particular help channel of choice where I could ask for more
help on the Python bindings, would that be needed (here, on
Subversion-users, directly to djames?)
E.g. any hint about this one?
> # use blame3, and for that, find a way to get a svn_diff_file_options_t
> # instance
>
... as the only reference I found to svn_diff_file_options_t in the
python bindings was in the docstring of svn_client_blame3.
-- Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Bug with http: URLs with functions from the client module in the Python bindings
Posted by David James <ja...@cs.toronto.edu>.
On 12/19/06, Christian Boos <cb...@neuf.fr> wrote:
> SIGSEGV
> 0xb7b4fefb in svn_auth_set_parameter (auth_baton=0x0, name=0x0,
> value=0x0) at auth.c:144
This is a bug. Instead of segfaulting, the Python bindings should
report that you forgot to initialize the suite of context providers in
the auth_baton. We should definitely patch the Python bindings to
check for whether auth_baton has been correctly initialized, because
this is a common typo which has bit many people. We should also add
some documentation which explains how to setup the auth_baton. (Anyone
care to submit a patch, either for the documentation, or for adding an
extra check? If you do, please CC me so that I will remember to review
it).
We should probably also patch the client.py test suite for the Python
bindings to correctly setup the auth_baton, so that people don't get
bit when they copy and paste examples from the test suite.
> > Alternatively, it can well be a misuse of the API, in which case I'd
> > be glad to get a few pointers to the relevant documentation (well,
> > besides the doxygen documentation for the C API and the Python binding
> > tests).
>
> So it looks very much like a misuse of the svn_client_ctx_t, which is
> used uninitialized.
> Any pointers about how to set this up correctly would be appreciated!
Here's how to setup the authentication providers. I borrowed this
example from http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn_export_empty_files.py
# Give the client context baton a suite of authentication
# providers.
providers = [
client.get_simple_provider(),
client.get_ssl_client_cert_file_provider(),
client.get_ssl_client_cert_pw_file_provider(),
client.get_ssl_server_trust_file_provider(),
client.get_username_provider(),
]
client_ctx.auth_baton = core.svn_auth_open(providers)
I tested adding this code to your script, and your script works great!
The new version of your script is attached and it works great on my
machine.
Cheers,
David
Re: Bug with http: URLs with functions from the client module in
the Python bindings
Posted by Christian Boos <cb...@neuf.fr>.
Hello again,
I'm forwarding a mail I received from Tim Hatch:
----
I wanted to let you know it happens on Linux too.
Christian Boos wrote:
> > Actually, the URL doesn't even need to be valid to trigger the crash:
> >
> > python C:/TMP/blame.py http://xxx
>
Happens with Linux too, with svn 1.4.2:
SIGSEGV
0xb7b4fefb in svn_auth_set_parameter (auth_baton=0x0, name=0x0,
value=0x0) at auth.c:144
Here's the backtrace:
#0 0xb7b4fefb in svn_auth_set_parameter (auth_baton=0x0, name=0x0,
value=0x0) at auth.c:144
#1 0xb789327d in svn_ra_dav__open (session=0x0, repos_URL=0xb7b1ce44
"http://xxx", callbacks=0x8130e50, callback_baton=0x0, config=0x0,
pool=0x8130e10) at session.c:758
#2 0xb7b3589a in svn_ra_open2 (session_p=0x0, repos_URL=0xb7b1ce44
"http://xxx", callbacks=0x0, callback_baton=0x0, config=0x0,
pool=0x8130e10) at ra_loader.c:294
...
----
>
> Alternatively, it can well be a misuse of the API, in which case I'd
> be glad to get a few pointers to the relevant documentation (well,
> besides the doxygen documentation for the C API and the Python binding
> tests).
So it looks very much like a misuse of the svn_client_ctx_t, which is
used uninitialized.
Any pointers about how to set this up correctly would be appreciated!
-- Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org