~Description of the problem:
I was using ctypes to get a directory file descriptor, and to do so I found this mailing list (https://lists.gt.net/python/dev/696028) from 2008 where a user wrote a piece that could do what the asking user and me were looking for.
What concerns me is how much this code has been used when I looked though Github and Google and came across the same exact pieces.
The code provided looks like this:
from ctypes import CDLL, c_char_p, c_int, Structure, POINTER
from ctypes.util import find_library
class c_dir(Structure):
"""Opaque type for directory entries, corresponds to struct DIR"""
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))
opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p
dirfd = c_lib.dirfd < -- IT FAILS HERE // STACK TRACE PROVIDED
dirfd.argtypes = [c_dir_p]
dirfd.restype = c_int
closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int
dir_p = opendir(".")
print "dir_p = %r" % dir_p
dir_fd = dirfd(dir_p)
print "dir_fd = %r" % dir_fd
print "closed (rc %r)" % closedir(dir_p)
When I implemented it in my machine, I changed it a bit so "opendir()" got its arguments from an imputed value, and the final program looks like this:
from ctypes import *
import sys
import ctypes
from ctypes.util import find_library
class c_dir(Structure):
"""Opaque type for directory entries, corresponds to struct DIR"""
def get_directory_file_descriptor(directory):
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))
opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p
dirfd = c_lib.dirfd < -- SAME. FAILS HERE.
dirfd.argtypes = [c_dir_p]
dirfd.restype = c_int
closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int
dir_p = opendir("%s" % directory)
print ("dir_p = %s:%r" % (directory, dir_p))
dir_fd = dirfd(dir_p)
print("dir_fd = %r" % dir_fd)
print ("closed (rc %r)" % closedir(dir_p))
get_directory_file_descriptor(sys.argv[1])
When I run it *with python 2.7*, the program runs normally if I enter the expected value, like "/home/". But if I don't, the program exits with a segmentation fault.
In python 3, it fails no matter what with a TypeError.
INPUT when NOT giving the error (in python 2.7): /home/
INPUT when giving the error: aaa
~Stack trace from python 2.7:
Program received signal SIGSEGV, Segmentation fault.
dirfd (dirp=0x0) at ../sysdeps/posix/dirfd.c:27
27 ../sysdeps/posix/dirfd.c: No such file or directory.
(gdb) bt
#0 dirfd (dirp=0x0) at ../sysdeps/posix/dirfd.c:27
#1 0x00007ffff6698e40 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#2 0x00007ffff66988ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3 0x00007ffff68a83df in _call_function_pointer (argcount=1, resmem=0x7fffffffd630,
restype=<optimized out>, atypes=<optimized out>, avalues=0x7fffffffd610,
pProc=0x7ffff78b8960 <dirfd>, flags=4353)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/callproc.c:837
#4 _ctypes_callproc (pProc=0x7ffff78b8960 <dirfd>, argtuple=<optimized out>, flags=4353,
argtypes=(<built-in method from_param of _ctypes.PyCPointerType object at remote 0xa2d370>,),
restype=<_ctypes.PyCSimpleType at remote 0xa38ce0>, checker=0x0)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/callproc.c:1180
#5 0x00007ffff68acd82 in PyCFuncPtr_call.lto_priv.107 (self=self@entry=0x7ffff7e322c0,
inargs=inargs@entry=(<LP_c_dir at remote 0x7ffff7ed45f0>,), kwds=kwds@entry=0x0)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/_ctypes.c:3954
#6 0x00000000004c15bf in PyObject_Call (kw=0x0, arg=(<LP_c_dir at remote 0x7ffff7ed45f0>,),
func=<_FuncPtr(__name__='dirfd') at remote 0x7ffff7e322c0>) at ../Objects/abstract.c:2546
#7 do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffffffd890,
func=<_FuncPtr(__name__='dirfd') at remote 0x7ffff7e322c0>) at ../Python/ceval.c:4567
#8 call_function (oparg=<optimized out>, pp_stack=0x7fffffffd890) at ../Python/ceval.c:4372
#9 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#10 0x00000000004c136f in fast_function (nk=<optimized out>, na=<optimized out>, n=1,
pp_stack=0x7fffffffd9b0, func=<function at remote 0x7ffff7e8f5f0>) at ../Python/ceval.c:4435
#11 call_function (oparg=<optimized out>, pp_stack=0x7fffffffd9b0) at ../Python/ceval.c:4370
#12 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#13 0x00000000004b9ab6 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#14 0x00000000004eb30f in PyEval_EvalCode (
locals={'c_void_p': <_ctypes.PyCSimpleType at remote 0xa3df50>, 'c_int64': <_ctypes.PyCSimpleType at remote 0xa1d7b0>, 'c_ssize_t': <_ctypes.PyCSimpleType at remote 0xa1d7b0>, 'c_longdouble': <_ctypes.PyCSimpleType at remote 0xa3c360>, 'Union': <_ctypes.UnionType at remote 0x7ffff6abc400>, 'cdll': <LibraryLoader(_dlltype=<type at remote 0xa3f780>) at remote 0x7ffff7e2c450>, 'c_wchar': <_ctypes.PyCSimpleType at remote 0xa3f0b0>, 'memset': <CFunctionType at remote 0x7ffff7fc6e20>, 'c_bool': <_ctypes.PyCSimpleType at remote 0xa3e620>, 'CFUNCTYPE': <function at remote 0x7ffff7e8f938>, 'DEFAULT_MODE': 0, 'string_at': <function at remote 0x7ffff7e30230>, 'c_voidp': <_ctypes.PyCSimpleType at re---Type <return> to continue, or q <return> to quit---
mote 0xa3df50>, '__name__': '__main__', 'c_uint64': <_ctypes.PyCSimpleType at remote 0xa367b0>, 'sizeof': <built-in function sizeof>, 'byref': <built-in function byref>, 'pointer': <built-in function pointer>, 'alignment': <built-in function alignment>, 'pydll': <LibraryLoader(_dlltype=<type at remote 0xa3fe50>) at remote 0x7ffff7e2c...(truncated),
globals={'c_void_p': <_ctypes.PyCSimpleType at remote 0xa3df50>, 'c_int64': <_ctypes.PyCSimpleType at remote 0xa1d7b0>, 'c_ssize_t': <_ctypes.PyCSimpleType at remote 0xa1d7b0>, 'c_longdouble': <_ctypes.PyCSimpleType at remote 0xa3c360>, 'Union': <_ctypes.UnionType at remote 0x7ffff6abc400>, 'cdll': <LibraryLoader(_dlltype=<type at remote 0xa3f780>) at remote 0x7ffff7e2c450>, 'c_wchar': <_ctypes.PyCSimpleType at remote 0xa3f0b0>, 'memset': <CFunctionType at remote 0x7ffff7fc6e20>, 'c_bool': <_ctypes.PyCSimpleType at remote 0xa3e620>, 'CFUNCTYPE': <function at remote 0x7ffff7e8f938>, 'DEFAULT_MODE': 0, 'string_at': <function at remote 0x7ffff7e30230>, 'c_voidp': <_ctypes.PyCSimpleType at remote 0xa3df50>, '__name__': '__main__', 'c_uint64': <_ctypes.PyCSimpleType at remote 0xa367b0>, 'sizeof': <built-in function sizeof>, 'byref': <built-in function byref>, 'pointer': <built-in function pointer>, 'alignment': <built-in function alignment>, 'pydll': <LibraryLoader(_dlltype=<type at remote 0xa3fe50>) at remote 0x7ffff7e2c...(truncated), co=0x7ffff7ed2d30) at ../Python/ceval.c:669
#15 run_mod.lto_priv () at ../Python/pythonrun.c:1376
#16 0x00000000004e5422 in PyRun_FileExFlags () at ../Python/pythonrun.c:1362
#17 0x00000000004e3cd6 in PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:948
#18 0x0000000000493ae2 in Py_Main () at ../Modules/main.c:640
#19 0x00007ffff7810830 in __libc_start_main (main=0x4934c0 <main>, argc=3, argv=0x7fffffffddf8,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffdde8) at ../csu/libc-start.c:291
#20 0x00000000004933e9 in _start ()
~The reason I thought that this may be a bug is because while researching the problem, I came across this other bug (https://bugzilla.redhat.com/show_bug.cgi?id=674206) where the user specifies a similar issue for RedHat.
The difference, though, is that in that case it could be fixed by specifying the argtypes, while in my case it's already specified.
I tested this on an Ubuntu 16.04 and ArchLinux machine and got the same results. |
➜
