Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"bad format char passed to Py_BuildValue" exception with the python bindings #642

Closed
glpatcern opened this issue Jan 11, 2018 · 3 comments
Closed

Comments

@glpatcern
Copy link
Contributor

After upgrading our servers to xrootd 4.8.0, a python exception started to be thrown as per the title, whereas the same client code did not throw any exceptions with xrootd 4.7 and earlier versions.

A way to reproduce the issue is:

from XRootD import client as XrdClient
fs = XrdClient.FileSystem('root://your-favourite-xrootd-server')
status, resp = fs.query(QueryCode.OPAQUE, "/boguspath")

And the output is:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.6/site-packages/XRootD/client/filesystem.py", line 141, in query
    status, response = self.__fs.query(querycode, arg, timeout)
SystemError: bad format char passed to Py_BuildValue

(while it should be "The server answered with an error")

With @simonmichal we tried some combinations and it appears as the bug was there already before 4.8, but it is somehow exposed only now. The reason for this is that if a valid path (e.g. "/tmp") is passed to fs.query(), then the same exception is thrown also by an older xrootd server.

To be noted that we see this on CASTOR by issuing a query handled by fsctl() on the server side.
(For reference, the CASTOR Jira issue is at https://its.cern.ch/jira/browse/CASTOR-5501, but a CERN account is needed to see it. All relevant information has been reported here though).

@simonmichal
Copy link
Contributor

This has been (potentially) fixed in b3419d2

Can we close it?

@glpatcern
Copy link
Contributor Author

...which made it to release 4.8.1, right? I have deployed it and I don't see the issue any longer, so I'm OK to close this.

@simonmichal
Copy link
Contributor

Perfect :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants