[C++-sig] Linux Intel compiler exception problems in Python

Raoul Gough RaoulGough at yahoo.co.uk
Thu Oct 9 15:32:15 CEST 2003

Some of the Boost.Python tests fail drastically with the Linux Intel
Compiler v7.1. It looks like throwing any C++ exception from code
executed within the Python interpreter will cause an abort. Can anyone
suggest a solution, or maybe another mailing list to get help?  Unless
this can be resolved, I don't see much Boost.Python code working
properly with this compiler.

This may be related to an issue mentioned on the babel-users list at

Tom Epperly <babel-users at llnl.gov> wrote (Thu, 24 Apr 2003 09:09:52
> It turns out that there seems to be a conflict between libgcc_s.so
> and icc's exception mechanism. I modified the Babel build to make
> sure that libgcc_s.so isn't linked in to shared libaries and
> executables. However, the Python backend uses Python's build system,
> and Python's build system uses the compiler and flags that Python
> was built with -- in most cases GCC. This causes a problem when you
> have a Python extension module wrapping icc compiled C++ that throws
> an exception.

This could mean that if Python was compiled with gcc, then icc
compiled extension modules cannot use C++ exceptions (although the
copy of Python I'm using doesn't depend on anything called
libgcc_s.so). Anyway, here's a simple example that demonstrates the

-----8<---- pythrow.cpp -----8<-----

#include <Python.h>

PyObject *throw_catch (PyObject *, PyObject *) {
  try { throw 0; } catch (int) { }
  PyErr_SetString (PyExc_RuntimeError, "Thrown and caught");
  return 0;

static PyMethodDef methods[] = {
  {"throw_catch",  throw_catch, METH_VARARGS, "Throw and catch an excpetion."},

extern "C" {
  void initpythrow(void) {
    Py_InitModule("pythrow", methods);


$ icc -I/usr/include/python2.2 -shared -g -o pythrow.so pythrow.cpp
$ python
Python 2.2.1 (#1, Aug 30 2002, 12:15:30)
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pythrow import throw_catch
>>> throw_catch()

Traceback from running in gdb looks like this:

Program received signal SIGABRT, Aborted.
[Switching to Thread 8192 (LWP 3274)]
0x42028cc1 in kill () from /lib/i686/libc.so.6
(gdb) where
#0  0x42028cc1 in kill () from /lib/i686/libc.so.6
#1  0x4002e07d in raise () from /lib/i686/libpthread.so.0
#2  0x4202a019 in abort () from /lib/i686/libc.so.6
#3  0x4007c9dc in GetCurrentFrame32 () from ./pythrow.so
#4  0x4007c240 in _Unwind_RaiseException () from ./pythrow.so
#5  0x4008948b in __cxa_throw ()
   from /opt/intel/compiler70/ia32/lib/libcxa.so.3
#6  0x4007c05b in throw_catch () at pythrow.cpp:4
#7  0x080ceb13 in PyCFunction_Call ()
#8  0x080796bc in eval_frame ()
#9  0x0807a10e in PyEval_EvalCodeEx ()
#10 0x08077025 in PyEval_EvalCode ()
#11 0x08096a49 in run_node ()
#12 0x080959c3 in PyRun_SimpleFileExFlags ()
#13 0x0809530a in PyRun_AnyFileExFlags ()
#14 0x0805381c in Py_Main ()
#15 0x08053269 in main ()
#16 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

Raoul Gough.
(setq dabbrev-case-fold-search nil)

More information about the Cplusplus-sig mailing list