stefan@opensolaris:~/hg/cpython$ ./python -m test -uall -v test_ctypes
== CPython 3.3.0a0 (default:5c8b6e03ebfe, Sep 7 2011, 13:41:08) [C]
==   Solaris-2.11-i86pc-i386-32bit little-endian
==   /export/home/stefan/hg/cpython/build/test_python_28849
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
test_cast (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_memmove (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_memset (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_string_at (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_wstring_at (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_chararray (ctypes.test.test_delattr.TestCase) ... ok
test_simple (ctypes.test.test_delattr.TestCase) ... ok
test_struct (ctypes.test.test_delattr.TestCase) ... ok
test_struct_by_value (ctypes.test.test_win32.Structures) ... ok
test_buffers (ctypes.test.test_unicode.StringTestCase) ... ok
test_func (ctypes.test.test_unicode.StringTestCase) ... ok
test_wcslen (ctypes.test.test_unicode.StringTestCase) ... ok
test_buffers (ctypes.test.test_unicode.UnicodeTestCase) ... ok
test_wcslen (ctypes.test.test_unicode.UnicodeTestCase) ... ok
test_compare (ctypes.test.test_simplesubclasses.Test) ... ok
test_ignore_retval (ctypes.test.test_simplesubclasses.Test) ... Fatal Python error: Segmentation fault

Current thread 0x00000001:
  File "/export/home/stefan/hg/cpython/Lib/ctypes/test/test_simplesubclasses.py", line 24 in test_ignore_retval
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 386 in _executeTestPart
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 441 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 493 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/runner.py", line 168 in run
  File "/export/home/stefan/hg/cpython/Lib/test/support.py", line 1293 in _run_suite
  File "/export/home/stefan/hg/cpython/Lib/test/support.py", line 1327 in run_unittest
  File "/export/home/stefan/hg/cpython/Lib/test/test_ctypes.py", line 13 in test_main
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 1140 in runtest_inner
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 916 in runtest
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 708 in main
  File "/export/home/stefan/hg/cpython/Lib/test/__main__.py", line 13 in <module>
  File "/export/home/stefan/hg/cpython/Lib/runpy.py", line 73 in _run_code
  File "/export/home/stefan/hg/cpython/Lib/runpy.py", line 160 in _run_module_as_main
Segmentation Fault (core dumped)

Code of the test:

    from ctypes import *
    def test_ignore_retval(self):
        # Test if the return value of a callback is ignored
        # if restype is None
        proto = CFUNCTYPE(None)
        def func():
            return (1, "abc", None)
        cb = proto(func)
        self.assertEqual(None, cb())

The crash occurs on self.assertEqual(None, cb()). I suppose that it occurs on cb().

Is CFUNCTYPE correct? Or should it be PYFUNCTYPE?

The segfault occurs both with CFUNCTYPE and PYFUNCTYPE in
ffi_prep_incoming_args_SYSV(). I'm not very familiar with
either suncc or the dbx debugger, and I can't get dbx to
step into that function (compiled with -g, libffi is not
stripped as far as I can see). Anyway, here's what I got:

(dbx) stop at ffi.c:403 
(2) stop at "ffi.c":403
(dbx) run
Running: python 
(process id 29932)
Python 3.3.0a0 (default:5c8b6e03ebfe+, Sep  7 2011, 15:48:46) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
Reading _struct.so
Reading libscf.so.1
Reading libuutil.so.1
Reading libgen.so.1
Reading libmd.so.1
Reading libmp.so.2
>>> proto = CFUNCTYPE(None)
>>> def func():
        return (1, "abc", None)
...
>>> cb = proto(func)
>>> cb()
stopped in ffi_closure_SYSV_inner at line 403 in file "ffi.c"
  403     ffi_prep_incoming_args_SYSV(args, respp, arg_area, cif);
(dbx) step
signal SEGV (no mapping at the fault address) in ffi_closure_SYSV_inner at line 403 in file "ffi.c"
  403     ffi_prep_incoming_args_SYSV(args, respp, arg_area, cif);

I see what is going on.  I don't think the 'libffi' code can be executed correctly when built by 'suncc'.  The code currently requires '__attribute__((regparm(1)))', which AFAICT is not implemented by 'suncc';  only 'gcc'.

Take a look at 'ffi_closure_SYSV_inner' in 'Modules/_ctypes/libffi/src/x86/ffi.c':

void FFI_HIDDEN ffi_closure_raw_SYSV (ffi_raw_closure *)
     __attribute__ ((regparm(1)));

...

/* This function is jumped to by the trampoline */

unsigned int FFI_HIDDEN
ffi_closure_SYSV_inner (closure, respp, args)
     ffi_closure *closure;
     void **respp;
     void *args;
{
  /* our various things...  */
  ffi_cif       *cif;
  void         **arg_area;

  cif         = closure->cif;
  arg_area    = (void**) alloca (cif->nargs * sizeof (void*));

The '__attribute__ ((regparm(1)))' causes the first parameter to be passed in a register and the rest of the parameters to be spilled to the stack.  For most (all?) x86 compilers, '%eax' is the first register used to pass parameters when the calling convention requires registers.

'suncc' ignores this attribute (you can see warnings by greping the build logs) and expects 'closure' to be on the stack where as the trampoline code puts it in '%eax'.  This causes a bogus 'closure' and a huge value for 'cif->nargs', which overflows the stack with 'alloca'.

If you build Python on OpenSolaris with 'gcc' (pkg install gcc-dev), then everything works fine.  Does 'libffi' claim to support Solaris Studio?  If not, then this can be closed.

Also see issue1544339.  This issue was run into there as well (although no one ever really diagnosed it).

According to the latest release notes (https://github.com/atgreen/libffi/blob/master/README) the Solaris compiler should be supported for building:

3.0.10 Aug-23-11
        Add support for Apple's iOS.
        Add support for ARM VFP ABI.
        Add RTEMS support for MIPS and M68K.
        Fix instruction cache clearing problems on
        ARM and SPARC.
        Fix the N64 build on mips-sgi-irix6.5.
        Enable builds with Microsoft's compiler.
        Enable x86 builds with Oracle's Solaris compiler.
        Fix support for calling code compiled with Oracle's Sparc
        Solaris compiler.
        Testsuite fixes for Tru64 Unix.
        Additional platform support.

So 'x86' builds work with 'suncc', but I guess no runtime testing was performed, which is consistent with (http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.11).  I will open a bug with 'libffi'.

Nice debugging work! I compiled --with-system-ffi and there the
issue seems fixed.

Do we have a libffi-3.0.10 release candidate in Modules/_ctypes?
The README says libffi-3.0.10, but the last commit for ffi.c was
17 months ago:

http://hg.python.org/cpython/log/b239b7d9f752/Modules/_ctypes/libffi/src/x86/ffi.c

I am not sure, but it does seem that way considering the most recent libffi says that 3.0.10 was released on Aug-23-11.  What is the process for updating libffi anyway?

Also, I posted a question concerning the Solaris Studio support on libffi-discuss: http://sourceware.org/ml/libffi-discuss/2011/msg00185.html.

Ping.  Could we update libffi for 3.3 final?

Coincidentally, I've just asked the Solaris buildbot owner if he could
try out the system libffi. I'm not sure if even the latest libffi
supports suncc out of the box. Meador, did you get any answers on
libffi-discuss?

Stefan, nope -- I never got a reply.  I will try again.

I can confirm (see attachement) that `--with-system-ffi` prevents the segfault on test_ctypes with the solaris compiler on Solaris11 x86.  I did not have to update the system at all for this switch to work.

Antoine, is it possible to add --with-system-ffi to the build rules
of the Solaris/suncc bot? This will prevent the segfaults.

> Antoine, is it possible to add --with-system-ffi to the build rules
> of the Solaris/suncc bot? This will prevent the segfaults.

Ok, done.

I can confirm this issue is resolved on Solaris 11 x86 and has been since '--with-system-ffi' was added to the build rules.

Given that --with-system-ffi works, I don't think we need the additional
burden of maintaining patches for libffi/suncc.