Python is dumping core after the test test_ctypes

[shashikala]

BPO	1582742
Nosy	@loewis, @theller
Files	testfail.txt setup.py.patch: setup.py patch for HPUX

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/theller'
closed_at = <Date 2008-04-03.21:09:43.934>
created_at = <Date 2006-10-23.09:42:48.000>
labels = ['interpreter-core']
title = 'Python is dumping core after the test test_ctypes'
updated_at = <Date 2008-04-03.21:09:43.933>
user = 'https://bugs.python.org/shashikala'

bugs.python.org fields:

activity = <Date 2008-04-03.21:09:43.933>
actor = 'theller'
assignee = 'theller'
closed = True
closed_date = <Date 2008-04-03.21:09:43.934>
closer = 'theller'
components = ['Interpreter Core']
creation = <Date 2006-10-23.09:42:48.000>
creator = 'shashikala'
dependencies = []
files = ['2195', '2196']
hgrepos = []
issue_num = 1582742
keywords = []
message_count = 10.0
messages = ['30355', '30356', '30357', '30358', '30359', '30360', '30361', '30362', '30363', '64907']
nosy_count = 4.0
nosy_names = ['loewis', 'nnorwitz', 'theller', 'shashikala']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1582742'
versions = ['Python 2.5']

[shashikala]

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,

[loewis]

Logged In: YES
user_id=21627

You will need to run Python in a debugger and find out where
it crashes.

[nnorwitz]

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'.

[theller]

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...).

[theller]

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

[theller]

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$

[loewis]

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).

[theller]

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.

[loewis]

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).

[theller]

See issue bpo-2544, this problem will be solved in Python 2.6. In Python
2.5, ctypes does not work on HPUX.