Package: python-ctypes
Version: 0.9.2-1
Severity: normal
Loading a function from libc causes a segfault on amd64. Functions from
other libraries seem to load okay.
(The following gdb session is using
LD_LIBRARY_PATH=/usr/lib/debug:/usr/X11R6/lib/debug which is why I'm
loading the debug libc, but the segfault happens with the non-debug libc
too.)
$ gdb python
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-linux"...(no debugging symbols found)
Using host libthread_db library "/usr/lib/debug/libthread_db.so.1".
(gdb) run
Starting program: /usr/bin/python
[Thread debugging using libthread_db enabled]
[New Thread 46912504471696 (LWP 6387)]
Python 2.3.5 (#2, Feb 10 2005, 02:35:35)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> l = cdll.LoadLibrary('/usr/lib/debug/libreadline.so.5')
>>> l.readline
<ctypes._CdeclFuncPtr object at 0x2aaaabca2df8>
>>> libc = cdll.LoadLibrary('/usr/lib/debug/libc.so.6')
>>> libc.puts
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912504471696 (LWP 6387)]
0x00002aaaaaab1a8f in _dl_lookup_symbol_internal () from
/lib64/ld-linux-x86-64.so.2
(gdb) bt
#0 0x00002aaaaaab1a8f in _dl_lookup_symbol_internal () from
/lib64/ld-linux-x86-64.so.2
#1 0x00002aaaab162f6d in _dl_sym (handle=0x2aaaabe338c8, name=0x2aaaabe338c4
"puts", who=0x77cb3)
at dl-sym.c:64
#2 0x00002aaaaacd75d4 in dlsym_doit (a=0x7fffffffed50) at dlsym.c:39
#3 0x00002aaaaaab5c50 in _dl_catch_error_internal () from
/lib64/ld-linux-x86-64.so.2
#4 0x00002aaaaacd786f in _dlerror_run (operate=0x2aaaaacd75c0 <dlsym_doit>,
args=0x7fffffffed50)
at dlerror.c:144
#5 0x00002aaaaacd75a6 in dlsym (handle=0x2aaaabe338c8, name=0x73 <Address 0x73
out of bounds>)
at dlsym.c:51
#6 0x00002aaaac83e9b2 in My_PyUnicode_AsWideChar ()
from /usr/lib/python2.3/site-packages/_ctypes.so
#7 0x00002aaaac83d0fd in My_PyUnicode_AsWideChar ()
from /usr/lib/python2.3/site-packages/_ctypes.so
#8 0x0000000000441f23 in _PyObject_SlotCompare ()
#9 0x00000000004164e0 in PyObject_Call ()
#10 0x0000000000463034 in PyEval_CallObjectWithKeywords ()
#11 0x0000000000462cc4 in PyEval_CallObjectWithKeywords ()
#12 0x00000000004610cc in Py_MakePendingCalls ()
#13 0x0000000000461d89 in PyEval_EvalCodeEx ()
#14 0x00000000004b0eda in PyStaticMethod_New ()
#15 0x00000000004164e0 in PyObject_Call ()
#16 0x0000000000462bd3 in PyEval_CallObjectWithKeywords ()
#17 0x00000000004186e5 in PyMethod_Fini ()
#18 0x00000000004338d7 in PyObject_GetAttr ()
#19 0x0000000000460b9b in Py_MakePendingCalls ()
#20 0x0000000000461d89 in PyEval_EvalCodeEx ()
#21 0x00000000004643d2 in PyEval_EvalCode ()
#22 0x000000000048e939 in PyRun_FileExFlags ()
#23 0x000000000048df6b in PyRun_InteractiveOneFlags ()
#24 0x000000000048dd5e in PyRun_InteractiveLoopFlags ()
#25 0x000000000048f1d3 in PyRun_AnyFileExFlags ()
#26 0x000000000040fd7a in Py_Main ()
#27 0x00002aaaab0803c1 in __libc_start_main (main=0x40f8c0 <main>, argc=1,
ubp_av=0x7ffffffff538,
init=0x60f7a8 <environ>, fini=0x2aaaaabbf000 <_rtld_local>,
rtld_fini=0x2aaaabe338c8,
stack_end=0x77cb3) at ../sysdeps/generic/libc-start.c:222
#28 0x000000000040f7ea in _start ()
A simple C test works:
#include <stdio.h>
#include <assert.h>
#include <dlfcn.h>
int main(int argc, char **argv) {
assert(argc>2);
char *libname = argv[1];
char *funcname = argv[2];
void *handle = dlopen(libname, RTLD_LAZY);
printf("%s handle: %p\n", libname, handle);
assert(handle);
void *sym = dlsym(handle, funcname);
printf("%s sym: %p\n", funcname, sym);
int r = dlclose(handle);
printf("dlclose ret: %i\n", r);
return 0;
}
$ make
cc -g -Wall -c -o dlopentest.o dlopentest.c
cc dlopentest.o -ldl -o dlopentest
$ ./dlopentest /lib/libc.so.6 puts
/lib/libc.so.6 handle: 0x2aaaaacc4000
puts sym: 0x2aaaaad2f4c0
dlclose ret: 0
And ctypes in 32 bit chroot works too:
$ python
Python 2.3.5 (#2, Feb 9 2005, 00:38:15)
[GCC 3.3.5 (Debian 1:3.3.5-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> libc = cdll.LoadLibrary('/lib/libc.so.6')
>>> libc.puts
<ctypes._CdeclFuncPtr object at 0x55b77b6c>
>>>
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.11.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Versions of packages python-ctypes depends on:
ii python 2.3.5-1 An interactive high-level object-o
ii python2.3-ctypes 0.9.2-1 Python package to create and manip
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
