_ctypes.dlopen does not include errno in OSError

[anacrolix]

BPO	12437
Nosy	@pitrou, @anacrolix
Files	dlopen_raise.py: test case

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-08-08.07:49:21.601>
created_at = <Date 2011-06-29.00:07:06.850>
labels = ['ctypes', 'type-bug']
title = '_ctypes.dlopen does not include errno in OSError'
updated_at = <Date 2011-08-08.07:49:21.600>
user = 'https://github.com/anacrolix'

bugs.python.org fields:

activity = <Date 2011-08-08.07:49:21.600>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2011-08-08.07:49:21.601>
closer = 'pitrou'
components = ['ctypes']
creation = <Date 2011-06-29.00:07:06.850>
creator = 'anacrolix'
dependencies = []
files = ['22512']
hgrepos = []
issue_num = 12437
keywords = []
message_count = 8.0
messages = ['139382', '139387', '141592', '141617', '141618', '141754', '141759', '141760']
nosy_count = 4.0
nosy_names = ['pitrou', 'anacrolix', 'santoso.wijaya', 'vladris']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue12437'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

[anacrolix]

_ctypes.dlopen is not including the errno when it raises OSError.

This occurs when attempting to load a library that doesn't exist, the error string given is clearly generated from an ENOENT.

joiner@dbssyd800:~$ python3 dlopen_raise.py
None
somelib.so: cannot open shared object file: No such file or directory

[santosowijaya]

On Windows:

>>> try:
...     ctypes.CDLL('somelib')
... except OSError as exc:
...     print repr(exc)
...     print exc.errno
...
WindowsError(126, 'The specified module could not be found')
22

[anacrolix]

Should I just submit a patch for this myself? Can someone confirm the behaviour is incorrect so I don't waste time fixing it?

[santosowijaya]

At least in Windows, the exception object has its winerror attribute correctly set to 126, which is also translated to POSIX errno with winerror_to_errno(); the latter gives us EINVAL (22).

[santosowijaya]

From what I gather from the code, when dlopen fails in POSIX platforms, ctypes raises an PyExc_OSError instantiated with a simple string (via PyErr_SetString()). I suppose this could be changed to raise a more complex tuple, instead (like its WindowsError equivalent when LoadLibrary fails in Windows platforms), but that might break existing code that relies on this behavior. 3.3 only?

[vladris]

Not sure how this can be fixed actually. I don't think PyErr_SetFromErrno instead of PyErr_SetString would work because as far as I can tell, standard does not mention dlopen making use of errno. Unlike Windows, where LoadLibrary will change last-error, if dlopen fails, only way to retrieve error is to dlerror which returns a string, no error code.

[pitrou]

Indeed, it looks more like a bug in the POSIX standard unfortunately.
I'm suggesting to close as "won't fix".

[anacrolix]

I didn't notice there was no use of errno. It's quite possible that dlopen might be used without the C library present, so perhaps this is why it wasn't included. The error strings however are very C-like, which made me think of this in the first place. Thanks all.