SIGTRAP received while calling a wrapped function with ""

[bruno dot lalande at gmail dot com]

We have a function that takes a std::string in parameter, and we wrap it using Boost.Python:

void foo(string s) {

cout << "foo" << endl;

}

BOOST_PYTHON_MODULE(mymodule) {

def("foo", &foo);

}

When we call it under gdb, we receive a SIGTRAP signal (see attachment). Note that the problem disappears if the std::string is replaced by a const char* or if we pass a non-empty literal string. Also, it only appears under gdb, a normal run won't make the program crash.

Here are the different platforms tested:

• win32 - python2.2.3 - gcc3.4.5 - boost1.35 - gdb6.8 : KO
• win32 - python2.5.2 - gcc3.4.5 - boost1.35 - gdb6.8 : KO
• win32 - python2.5.2 - gcc3.4.5 - boost1.36 - gdb6.8 : KO
• win32 - python2.5.2 - gcc4.2.1-sjlj - boost1.36 - gdb6.8 : KO
• redhat 7.2 - python2.4. - gcc3.3.6 - boost1.35 - gdb5.0 : OK
• ubuntu 8.10 - python2.5.2 - gcc4.3.2 - boost1.35 - gdb6.8: OK

So the problem seems to be reproducible only with win32.

Bruno

[Dave Abrahams]

There isn't nearly enough information here to verify that this is a Boost.Python problem, as opposed to a gdb problem, or, for example, a problem on your end with linking incompatible libraries. I can't even see any Boost.Python symbols in your stack backtrace.

Given how reliable Boost.Python has been in the past, and how stable it's been recently (almost no changes to the codebase), the most appropriate action seems to me to be to close the ticket. If you find more information that points at Boost.Python, please feel free to reopen the ticket.

[anonymous]

Indeed, those informations were missing, sorry for that.

Here is where the different things come from:

• python is the precompiled official package
• gcc and gdb are the precompiled packages provided by the mingw project
• boost has been built using: bjam -g --v2 --toolset=gcc --mno-cygwin --with-python python-debugging=on variant=debug threading=single link=shared
• bjam is the 3.1.16 precompiled binary provided by Boost
• the mymodule module has been compiled using: g++ -Wall -O0 -DBUILD_DLL -g -DBOOST_DEBUG_PYTHON -IC:\Python22\include -LC:\Python22\libs (+ the -I and -L options to our compiled Boost.Python)

You will find in the new attachment a trace that shows some Boost.Python debug informations. We begin by placing a pending breakpoint on foo, then we import mymodule. We first call the foo() function with a non-empty string, which works well. Then we do the same but with an empty string, which results in a SIGTRAP raised while we are in python/detail/caller.hpp:225.

We know the stability of Boost.Python, that we heavily use. The point is that this problem can occur under this form only in gdb, as "SIGTRAP is the signal thrown by computer programs when a condition arises that a debugger has requested to be informed of" (according to wikipedia). So it won't arise in a normal run, but the potential problem it shows can have another consequence later. That's why we thought it could be useful to report it here. This being said, it's very difficult to make sure it's not a gdb bug. We are open to any suggestion of test that could be done to clarify things.

Bruno

[Dave Abrahams]

Replying to anonymous:

Indeed, those informations were missing, sorry for that.

Here is where the different things come from:

• python is the precompiled official package
• gcc and gdb are the precompiled packages provided by the mingw project
• boost has been built using: bjam -g --v2 --toolset=gcc --mno-cygwin --with-python python-debugging=on variant=debug threading=single link=shared

Are you aware that, as documented at http://www.boost.org/doc/libs/1_37_0/libs/python/doc/building.html#id40, Python doesn't ship a python debugging build by default? This looks, as I suggested, like a problem on your end with linking incompatible libraries.