[C++-sig] preventing boost::python::throw_error_already_set

[troy d. straszheim]

Hey Leonard,

Here's a short doc about running python scripts that load
boost::python bindings under gdb:

   http://software.icecube.wisc.edu/offline-software.trunk/gdb_python.html

In short (i'm guessing this is more or less what you'll need):

   gdb --args /usr/bin/python /path/to/my/python/script.py
   run
     # it runs, throws an exception, but the stacktrace isn't helpful
   catch throw # this only works after the first run
   run
   # jackpot, you're at the point of the throw

-t






Leonard Ritter wrote:
> On Sun, Dec 14, 2008 at 11:22 PM, Leonard Ritter <paniq at paniq.org> wrote:
> 
>> That's hard to tell without more context: Who is doing the iteration, for
>>> example ?
>>
> I'm sorry. I was a bit stressed out yesterday. I recognize that you only
> want to help, and I should be more patient.
> 
> Here is the top part of a stack trace, as it usually occurs:
> 
> #0  0xb65593dc in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
> #1  0xb6a85a9e in boost::python::throw_error_already_set ()
>    from /usr/lib/libboost_python-gcc42-1_34_1-py25.so.1.34.1
> #2  0xb6a88ab1 in boost::python::objects::stop_iteration_error ()
>    from /usr/lib/libboost_python-gcc42-1_34_1-py25.so.1.34.1
> #3  0xb6ca38c3 in
> boost::python::objects::iterator_range<boost::python::return_internal_reference<1u,
> boost::python::default_call_policies>,
> __gnu_cxx::__normal_iterator<halebopp::wave_range*,
> std::vector<halebopp::wave_range, std::allocator<halebopp::wave_range> > >
>> ::next::operator() (this=0x9931cec,
>     self=@0x91fcfcc) at /usr/include/boost/python/object/iterator.hpp:64
> 
> This problem occurred first when iterating an array that was exported
> through the indexing suite. I do not have anything else that uses
> StopIteration, so I can't say if it's really a problem of the indexing
> suite. My guess is: no. When I rewrote the offending code to be a simple
> get-by-index operation, the next (above) part where an iteration would be
> caused inside C++ code created a problem. So somehow I end up with an
> unhandled python exception in boost that does not get forwarded - my guess.
> 
> Could this in some way relate to assertions (put by assert()) put in the C++
> code? Something like: boost catches these assertions, converts them into
> exceptions, then iterates a bit, hits a StopIteration and has the previously
> unhandled exception still active? I am just wildly guessing here.
> 
> Please help!
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig