Zachary Ware added the comment:
This one is officially weird.
I can reliably reproduce the segfault in test_ascii_formatd on OSX with ICC 15
or 16, using the included libffi in Modules/_ctypes/libffi_osx. There are also
segfaults in test_ctypes, test_multiprocessing, and test_threading (all
stemming from an issue in ctypes).
Using libffi from Homebrew and --with-system-ffi, all the segfaults go away,
and in fact all tests pass (with --with-icc from #25827, which adds '-fp-model
strict' to CFLAGS). The bundled 'nearly vanilla' libffi doesn't work with OSX;
it doesn't make it through configure.
Somehow, argcount in _ctypes_callproc is being corrupted, but applying this
patch somehow makes test_ascii_formatd pass:
diff -r 937774aa1853 Modules/_ctypes/callproc.c
--- a/Modules/_ctypes/callproc.c Mon Dec 14 03:41:59 2015 +0000
+++ b/Modules/_ctypes/callproc.c Fri Dec 18 02:10:04 2015 -0600
@@ -1168,6 +1168,7 @@
PyErr_NoMemory();
goto cleanup;
}
+ printf("line 1171, argcount %zd", argcount);
for (i = 0; i < argcount; ++i) {
atypes[i] = args[i].ffi_type;
if (atypes[i]->type == FFI_TYPE_STRUCT)
I have absolutely no idea why that should work. Adding that line before the
previous statement still results in segfault, and adding it anywhere after line
1178 also still results in segfault. Even with the magic patch, test_ctypes
still segfaults elsewhere. I'm out of my depth as to what could be causing
this or how to further diagnose it.
As a workaround, would it be kosher to mandate --with-system-ffi on Darwin when
CC=icc? As I recall, the custom libffi is necessary for regular OSX builds to
accommodate fat binaries; how concerned are we about supporting fat binaries
with ICC?
----------
components: +ctypes
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue25589>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
