[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
SourceForge.net
noreply at sourceforge.net
Fri Jul 13 19:55:29 CEST 2007
Bugs item #1582742, was opened at 2006-10-23 11:42
Message generated for change (Settings changed) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shashi (shashikala)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Python is dumping core after the test test_ctypes
Initial Comment:
Hi ,
Iam building Python-2.5 on HPUX Itanium. The
compilation is done without any error, but while
testing the same using gmake test it is dumping core
telling "Segementation Fault" after the test
test_ctypes. Please help me in resolving the above
issue.Iam attaching the output of gmake test.
Thanks in advance,
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2007-02-01 20:54
Message:
Logged In: YES
user_id=21627
Originator: NO
configure.in sets LDSHARED to "ld -b" around line 1477. Whether this is a
bug, I don't know - there may have been HP-UX systems where this was the
proper way of doing things.
These days, on most systems (not sure whether this includes HP-UX), direct
linking with ld is discouraged; one should use the C compiler for linking.
Unless somebody steps in and can tell the full story, I would advise to
use $(CC) for linking on HPUX if the compiler is gcc (see SunOS processing
as to how to determine gcc).
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2007-02-01 20:12
Message:
Logged In: YES
user_id=11105
Originator: NO
Martin, -lgcc alone does not work, I had to specify library_dirs.
Linking is done with 'ld -l' by default.
How do I specify that gcc should be used for linking (and should I expect
'configure' to determine this correctly)? Is it a bug in 'configure'?
Ok: when I export LDSHARED="gcc -shared", than do configure and make the
missing symbol error disappears, even without using -lgcc.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2007-01-31 22:58
Message:
Logged In: YES
user_id=21627
Originator: NO
Thomas, the libgcc problem might be a gcc installation problem. Just
specifying -lgcc should be enough to get libgcc linked in. Furthermore,
depending on how the linking is done (gcc -shared?), it shouldn't be
necessary *at all* to provide -lgcc. This isn't so much a HPUX question but
more a gcc question: if you link with gcc, it *ought* to work (if you link
with ld(1), you are on your own).
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2007-01-31 22:00
Message:
Logged In: YES
user_id=11105
Originator: NO
I did also try the Python 2.5 release tarball and could not reproduce the
bug. Machine info:
bash-3.00$ uname -a
HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license
bash-3.00$ gcc --version
gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
bash-3.00$ ./python
Python 2.5 (r25:51908, Jan 31 2007, 15:56:22)
[GCC 3.4.3] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>>
bash-3.00$
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2007-01-31 21:15
Message:
Logged In: YES
user_id=11105
Originator: NO
I finally found time (and energy) to try out the td176 HPUX host on HP
testdrive.
I downloaded the python25.tar.bz2 snapshot from svn.python.org, and built
it with the installed gcc 3.4.3. First, I got errors in the ctypes tests
because the _ctypes_test extension/shared library could not be loaded
because of a missing symbol __divsf3.
Googling around I found http://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
which mentions a GCC runtime library libgcc.a (see the link 'soft float
library routines' on ths page). When this library is specified when
building _ctypes_test.so, all ctypes unittests pass. Without any crash.
It is strange, to link against the libgcc.a library it seems needed to
specify the location of the library
'/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.3/' - no idea why. Can some HPUX
guru provide some insight?
The attached patch to setup.py is what was needed, but it is a hack of
course.
File Added: setup.py.patch
----------------------------------------------------------------------
Comment By: Thomas Heller (theller)
Date: 2006-11-02 22:02
Message:
Logged In: YES
user_id=11105
Neal, I see no connection between the code that you show and
the stack dump.
For the failure when importing ctypes.test.test_cfuncs it
seems that a library (?) is missing
that _ctypes_test.so requires. Any idea? (I know that HP
offers shell access to HPUX boxes,
but I hesitate to try that out...).
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-10-29 03:05
Message:
Logged In: YES
user_id=33168
This is the code that crashes:
from ctypes import *
print cast(c_void_p(0), POINTER(c_int))
***
#0 ffi_call_unix+0x20 ()
at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63
#1 0x2000000079194d30:0 in ffi_call (cif=0x7fffe020,
fn=0x7913a860,
rvalue=0x7fffe090, avalue=0x7fffe070)
at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372
#2 0x20000000791762f0:0 in _call_function_pointer (flags=4101,
pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050,
restype=0x40081de8, resmem=0x7fffe090, argcount=3)
at trunk/Modules/_ctypes/callproc.c:665
#3 0x20000000791781d0:0 in _CallProc (pProc=0x7913a860,
argtuple=0x401cdd78,
flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8,
checker=0x0)
at trunk/Modules/_ctypes/callproc.c:1001
#4 0x2000000079165350:0 in CFuncPtr_call (self=0x4007abe8,
inargs=0x401cdd78,
kwds=0x0)
at trunk/Modules/_ctypes/_ctypes.c:3364
***
Also note there are a bunch of errors like this:
Warning: could not import ctypes.test.test_cfuncs:
Unsatisfied code symbol '__divsf3' in load module
'trunk/build/lib.hp-ux-B.11.23-ia64-2.6/_ctypes_test.so'.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2006-10-25 10:41
Message:
Logged In: YES
user_id=21627
You will need to run Python in a debugger and find out where
it crashes.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470
More information about the Python-bugs-list
mailing list