msg152735 - (view) |
Author: Graeme Glass (graemeglass) |
Date: 2012-02-06 13:30 |
When doing something obviously incorrect (read, wrong/stupid) while calling libX11.so.6 via ctypes, it causes a Segmentation fault, which in turn cause the python interpreter to fall over with a Segmentation fault. My question is, is this the correct behaviour? Should it seg fault or just throw an exception? Details below. graeme@roger:~$ uname -a Linux roger 3.0.0-15-generic-pae #26-Ubuntu SMP Fri Jan 20 17:07:31 UTC 2012 i686 i686 i386 GNU/Linux graeme@roger:~$ python Python 2.7.2+ (default, Oct 4 2011, 20:03:08) [GCC 4.6.1] on linux2 graeme@roger:~$ python2.6 Python 2.6.7 (r267:88850, Aug 11 2011, 12:16:10) [GCC 4.6.1] on linux2 ## The example code graeme@roger:~$ cat xtest.py from ctypes import cdll dll = cdll.LoadLibrary('libX11.so.6') d = dll.XOpenDisplay(None) root = dll.XDefaultRootWindow(d) dll.XWarpPointer(d,None,root,0,0,0,0,20,39) dll.XCloseDisplay(d) dll.XCloseDisplay(d) #2nd call, should not be called, is not needed. Causes seg fault. ##The results graeme@roger:~$ pdb2.7 xtest.py > /home/graeme/xtest.py(1)() -> from ctypes import cdll (Pdb) c Segmentation fault graeme@roger:~$ python2.7 xtest.py Segmentation fault graeme@roger:~$ ipython-2.7 xtest.py Segmentation fault graeme@roger:~$ ipython-2.6 xtest.py Segmentation fault graeme@roger:~$ gdb python2.7 (gdb) set args xtest.py (gdb) run Starting program: /usr/bin/python xtest.py [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. __GI___libc_free (mem=0x151) at malloc.c:3709 3709 malloc.c: No such file or directory. in malloc.c graeme@roger:~$ python2.6 xtest.py *** glibc detected *** python2.6: double free or corruption (!prev): 0x083533a0 *** ======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x6ebc2)[0xb7402bc2] /lib/i386-linux-gnu/libc.so.6(+0x6f862)[0xb7403862] /lib/i386-linux-gnu/libc.so.6(cfree+0x6d)[0xb740694d] /usr/lib/i386-linux-gnu/libX11.so.6(+0x9232b)[0xb6ff732b] /usr/lib/i386-linux-gnu/libX11.so.6(_XFreeDisplayStructure+0x16f)[0xb6f8bddf] /usr/lib/i386-linux-gnu/libX11.so.6(XCloseDisplay+0xd9)[0xb6f78179] /usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call_SYSV+0x1a)[0xb70c548a] /usr/lib/python2.6/lib-dynload/_ctypes.so(ffi_call+0x6f)[0xb70c51bf] /usr/lib/python2.6/lib-dynload/_ctypes.so(_CallProc+0x2c2)[0xb70bfd12] /usr/lib/python2.6/lib-dynload/_ctypes.so(+0x61ed)[0xb70b71ed] python2.6(PyObject_Call+0x4d)[0x80648cd] python2.6(PyEval_EvalFrameEx+0x3984)[0x80d6514] python2.6(PyEval_EvalCodeEx+0x882)[0x80d96e2] python2.6(PyEval_EvalCode+0x57)[0x80d97e7] python2.6(PyRun_FileExFlags+0xa6)[0x80f8b26] python2.6(PyRun_SimpleFileExFlags+0xc6)[0x80f98b6] python2.6(Py_Main+0xa49)[0x805be59] python2.6(main+0x1b)[0x805affb] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb73ad113] python2.6[0x805b021] ======= Memory map: ======== 08048000-08255000 r-xp 00000000 08:06 4459238 /usr/bin/python2.6 08255000-08256000 r--p 0020c000 08:06 4459238 /usr/bin/python2.6 08256000-082a5000 rw-p 0020d000 08:06 4459238 /usr/bin/python2.6 082a5000-082ae000 rw-p 00000000 00:00 0 082d2000-08374000 rw-p 00000000 00:00 0 [heap] b6e00000-b6e21000 rw-p 00000000 00:00 0 b6e21000-b6f00000 ---p 00000000 00:00 0 b6f28000-b6f44000 r-xp 00000000 08:06 2097174 /lib/i386-linux-gnu/libgcc_s.so.1 b6f44000-b6f45000 r--p 0001b000 08:06 2097174 /lib/i386-linux-gnu/libgcc_s.so.1 b6f45000-b6f46000 rw-p 0001c000 08:06 2097174 /lib/i386-linux-gnu/libgcc_s.so.1 b6f46000-b6f63000 r-xp 00000000 08:06 4458588 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0 b6f63000-b6f64000 r--p 0001c000 08:06 4458588 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0 b6f64000-b6f65000 rw-p 0001d000 08:06 4458588 /usr/lib/i386-linux-gnu/libxcb.so.1.1.0 b6f65000-b7096000 r-xp 00000000 08:06 4458582 /usr/lib/i386-linux-gnu/libX11.so.6.3.0 b7096000-b7097000 ---p 00131000 08:06 4458582 /usr/lib/i386-linux-gnu/libX11.so.6.3.0 b7097000-b7098000 r--p 00131000 08:06 4458582 /usr/lib/i386-linux-gnu/libX11.so.6.3.0 b7098000-b709a000 rw-p 00132000 08:06 4458582 /usr/lib/i386-linux-gnu/libX11.so.6.3.0 b709a000-b709b000 rw-p 00000000 00:00 0 b70b1000-b70c8000 r-xp 00000000 08:06 3634 /usr/lib/python2.6/lib-dynload/_ctypes.so b70c8000-b70cb000 r--p 00017000 08:06 3634 /usr/lib/python2.6/lib-dynload/_ctypes.so b70cb000-b70ce000 rw-p 0001a000 08:06 3634 /usr/lib/python2.6/lib-dynload/_ctypes.so b70ce000-b710f000 rw-p 00000000 00:00 0 b7110000-b7111000 r--p 00299000 08:06 4464349 /usr/lib/locale/locale-archive b7111000-b7311000 r--p 00000000 08:06 4464349 /usr/lib/locale/locale-archive b7311000-b7394000 rw-p 00000000 00:00 0 b7394000-b750a000 r-xp 00000000 08:06 2097561 /lib/i386-linux-gnu/libc-2.13.so b750a000-b750c000 r--p 00176000 08:06 2097561 /lib/i386-linux-gnu/libc-2.13.so b750c000-b750d000 rw-p 00178000 08:06 2097561 /lib/i386-linux-gnu/libc-2.13.so b750d000-b7511000 rw-p 00000000 00:00 0 b7511000-b7539000 r-xp 00000000 08:06 2097567 /lib/i386-linux-gnu/libm-2.13.so b7539000-b753a000 r--p 00028000 08:06 2097567 /lib/i386-linux-gnu/libm-2.13.so b753a000-b753b000 rw-p 00029000 08:06 2097567 /lib/i386-linux-gnu/libm-2.13.so b753b000-b754e000 r-xp 00000000 08:06 2098068 /lib/i386-linux-gnu/libz.so.1.2.3.4 b754e000-b754f000 r--p 00012000 08:06 2098068 /lib/i386-linux-gnu/libz.so.1.2.3.4 b754f000-b7550000 rw-p 00013000 08:06 2098068 /lib/i386-linux-gnu/libz.so.1.2.3.4 b7550000-b76dd000 r-xp 00000000 08:06 2097531 /lib/i386-linux-gnu/libcrypto.so.1.0.0 b76dd000-b76eb000 r--p 0018c000 08:06 2097531 /lib/i386-linux-gnu/libcrypto.so.1.0.0 b76eb000-b76f1000 rw-p 0019a000 08:06 2097531 /lib/i386-linux-gnu/libcrypto.so.1.0.0 b76f1000-b76f4000 rw-p 00000000 00:00 0 b76f4000-b773c000 r-xp 00000000 08:06 2097532 /lib/i386-linux-gnu/libssl.so.1.0.0 b773c000-b773e000 r--p 00047000 08:06 2097532 /lib/i386-linux-gnu/libssl.so.1.0.0 b773e000-b7741000 rw-p 00049000 08:06 2097532 /lib/i386-linux-gnu/libssl.so.1.0.0 b7741000-b7743000 r-xp 00000000 08:06 2099412 /lib/i386-linux-gnu/libutil-2.13.so b7743000-b7744000 r--p 00001000 08:06 2099412 /lib/i386-linux-gnu/libutil-2.13.so b7744000-b7745000 rw-p 00002000 08:06 2099412 /lib/i386-linux-gnu/libutil-2.13.so b7745000-b7746000 rw-p 00000000 00:00 0 b7746000-b7749000 r-xp 00000000 08:06 2097565 /lib/i386-linux-gnu/libdl-2.13.so b7749000-b774a000 r--p 00002000 08:06 2097565 /lib/i386-linux-gnu/libdl-2.13.so b774a000-b774b000 rw-p 00003000 08:06 2097565 /lib/i386-linux-gnu/libdl-2.13.so b774b000-b7762000 r-xp 00000000 08:06 2099407 /lib/i386-linux-gnu/libpthread-2.13.so b7762000-b7763000 r--p 00016000 08:06 2099407 /lib/i386-linux-gnu/libpthread-2.13.so b7763000-b7764000 rw-p 00017000 08:06 2099407 /lib/i386-linux-gnu/libpthread-2.13.so b7764000-b7766000 rw-p 00000000 00:00 0 b7770000-b7775000 r-xp 00000000 08:06 4458586 /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0 b7775000-b7776000 r--p 00004000 08:06 4458586 /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0 b7776000-b7777000 rw-p 00005000 08:06 4458586 /usr/lib/i386-linux-gnu/libXdmcp.so.6.0.0 b7777000-b7779000 r-xp 00000000 08:06 4458584 /usr/lib/i386-linux-gnu/libXau.so.6.0.0 b7779000-b777a000 r--p 00001000 08:06 4458584 /usr/lib/i386-linux-gnu/libXau.so.6.0.0 b777a000-b777b000 rw-p 00002000 08:06 4458584 /usr/lib/i386-linux-gnu/libXau.so.6.0.0 b777b000-b777c000 rwxp 00000000 00:00 0 b777c000-b777e000 rw-p 00000000 00:00 0 b777e000-b777f000 r-xp 00000000 00:00 0 [vdso] b777f000-b779d000 r-xp 00000000 08:06 2097504 /lib/i386-linux-gnu/ld-2.13.so b779d000-b779e000 r--p 0001d000 08:06 2097504 /lib/i386-linux-gnu/ld-2.13.so b779e000-b779f000 rw-p 0001e000 08:06 2097504 /lib/i386-linux-gnu/ld-2.13.so bfb52000-bfb73000 rw-p 00000000 00:00 0 [stack] Aborted |
|
|
msg152739 - (view) |
Author: Ramchandra Apte (Ramchandra Apte) * |
Date: 2012-02-06 15:24 |
It is the correct behaviour for an invalid usage to segfault and is also mentioned in the documentation. Can somebody close this bug as invalid? |
|
|
msg152744 - (view) |
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *  |
Date: 2012-02-06 16:36 |
[Please do not change issue titles - your recommendation was enough] Indeed, incorrect usage of ctypes can crash the program, and there is nothing Python can do. But I could not find any warning about this in the documentation, except maybe this sentence: "There are, however, enough ways to crash Python with ctypes, so you should be careful anyway." Let's turn this into a doc issue, then. |
|
|
msg153306 - (view) |
Author: STINNER Victor (vstinner) *  |
Date: 2012-02-14 00:10 |
> Should it seg fault or just throw an exception? Python cannot do anything useful on such fatal error. In Python 3.3, there is a faulthandler module which can help to debug: it dumps the traceback of all threads on such fatal error. It is also available as a third party module on PyPI: http://pypi.python.org/pypi/faulthandler |
|
|
msg154848 - (view) |
Author: Westley MartÃnez (westley.martinez) * |
Date: 2012-03-03 19:57 |
Hi I found this bug randomly and have made two small patches to change the documentation. One assumes that the faulthandler module is available for 3.3. The other patch is for earlier versions of Python. |
|
|
msg178560 - (view) |
Author: Ramchandra Apte (Ramchandra Apte) * |
Date: 2012-12-30 08:28 |
Bump. |
|
|
msg178561 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2012-12-30 09:20 |
The reference to faulthandler is a good addition. The other added sentence reads repetitive and can be left out. Proposal: There are, however, enough ways to crash Python with :mod:`ctypes`, so you should be careful anyway. The :mod:`faulthandler` module can be helpful in debugging crashes, e.g. from segmentation faults produced by erroneous C library calls. |
|
|
msg178633 - (view) |
Author: Meador Inge (meador.inge) *  |
Date: 2012-12-31 00:57 |
Georg's proposal seems reasonable to me sans one very minor nit. I think the e.g. bit is better off parenthesized: There are, however, enough ways to crash Python with :mod:`ctypes`, so you -should be careful anyway. +should be careful anyway. The :mod:`faulthandler` module can be helpful in +debugging crashes (e.g. from segmentation faults produced by erroneous C +library calls). If there are no objections, then I will go ahead and commit this version. |
|
|
msg178651 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2012-12-31 08:16 |
LGTM. |
|
|
msg196516 - (view) |
Author: Westley MartÃnez (westley.martinez) * |
Date: 2013-08-30 06:35 |
Can we have this committed? |
|
|
msg199056 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-10-06 08:50 |
New changeset 1e163fdf8cf3 by Georg Brandl in branch '3.3': Closes #13951: Add a "faulthandler" reference in the ctypes docs talking about crashes. http://hg.python.org/cpython/rev/1e163fdf8cf3 |
|
|