Boost C++ Libraries: Ticket #2555: SIGTRAP received while calling a wrapped function with ""

attachment set

bruno dot lalande at gmail dot com — Mon, 01 Dec 2008 16:02:35 GMT

attachment → readme.txt

status changed; resolution set

Dave Abrahams — Mon, 01 Dec 2008 16:41:41 GMT

status new → closed
resolution → invalid

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.

attachment set

bruno dot lalande at gmail dot com — Tue, 02 Dec 2008 13:59:53 GMT

attachment → trace.txt

anonymous — Tue, 02 Dec 2008 14:05:50 GMT

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

status changed; resolution deleted

Fri, 05 Dec 2008 09:15:53 GMT

status closed → reopened
resolution invalid

Dave Abrahams — Tue, 23 Dec 2008 09:20:15 GMT

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.