New submission from Bob <balget...@protonmail.com>:

~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 r
 emote 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.

----------
components: ctypes
messages: 329367
nosy: execve
priority: normal
severity: normal
status: open
title: Ctypes segfault or TypeError tested for python2.7 and 3
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35180>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to