On Wed, 20 Mar 2013 15:52:52 -0000, Jim Bosch <tallji...@gmail.com> wrote:
http://www.boost.org/doc/libs/1_53_0/libs/python/doc/v2/faq.html#threadsupport
There are other people on this list who know a lot more about this than
I do, but my understanding has always been that it you use Boost.Python
with threading on the C++ side, all bets are off, unless the Python
interaction is strictly limited to one thread.
Hi again list,
So I'm still working on this object de-allocation seg-fault problem and
think I've pinpointed the problem... Any advice on what to do from here
would be really appreciated!
The class I'm trying to wrap (Environment) has the following member
definition:-
mutable FastMutex m_CacheMutex;
The FastMutex class is implemented in the 3rd party library, and on Linux
at least, is essentially just a wrapper around pthread_mutex.
I wrote a stripped down version of 'Environment' yesterday, and when I
commented out that FastMutex definition and all uses of it in
'Environment', then the seg-fault doesn't occur. If I uncomment only the
definition, but leave its uses commented, then the seg-fault reappears. I
guess the above definition must also be initialising the instance, as I
can't see it being initialised anywhere else in the class...
(Interestingly, the seg-fault doesn't occur if I compile with Intel's
compiler instead of gcc, but that's not good enough really; valgrind will
probably still complain).
I noticed that the 3rd party library has a 'WRITE_MUTEX_EVENT' macro,
which was a no-op, until I recompiled it with a LOG_MUTEX_EVENTS
definition, so, I did that...
With mutex events being logged, I can see the difference between when this
FastMutex is defined and when its not: just before the seg-fault, the
following call is made:-
pthread_mutex_destroy(&m_Handle);
where 'm_Handle' is a member variable of a friend class of 'FastMutex'. On
Linux, 'm_Handle' is essentially declared as a pthread_mutex_t.
So, in Environment's destructor, which I thought was a no-op, FastMutex's
destructor is also being called. Now, that's a bit of a bummer. As far as
I can tell (I'm still very new to C++; coming from Python), unlike how I
hacked the initialiser list, I can't do any work either side of the
chained base class destructor calls.
-------------------------------------------
In an attempt to do that though, I did try this (didn't work):-
namespace mylib {
class MyEnv
: public notmylib::Environment
{
public:
MyEnv();
~MyEnv();
// ....
private:
PyThreadState * _save;
}
}
mylib::MyEnv::~MyEnv()
{
Py_UNBLOCK_THREADS;
Environment::~Environment(); ///< compile error
Py_BLOCK_THREADS;
}
No doubt obvious to anyone more experienced with C++, but this raises a
compile error...
-------------------------------------------
The next thing I thought to try and do, was to get the logic inside an
exposed '__del__' function:-
static void mylib::DelMyEnv(MyEnv* env)
{
PyThreadState * _save;
_save = PyEval_SaveThread();
delete env; ////<-- crash
PyEval_RestoreThread(_save);
}
BOOST_PYTHON_MODULE(pylib)
{
class_<mylib::MyEnv, noncopyable>("Env", init<>() )
.def("__del__", mylib::DelMyEnv )
;
}
However, that also segfaults on the 'delete env' line, with gdb printing
the message:-
Error in `/usr/local/bin/python2-dbg': free(): invalid pointer:
0x000000000096fe50 ***
That 'invalid pointer' address is for the 'env' pointer variable. With the
power of print statements, I can see that I get into MyEnv's destructor,
then Environment's destructor, but before that returns, crash..
The top of the backtrace is:
#0 0x00007ffff74582c5 in raise () from /usr/lib/libc.so.6[0/9672]
#1 0x00007ffff7459748 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff7497f7b in __libc_message () from /usr/lib/libc.so.6
#3 0x00007ffff749db06 in malloc_printerr () from /usr/lib/libc.so.6
#4 0x00007ffff749e883 in _int_free () from /usr/lib/libc.so.6
#5 0x00007ffff6b0e377 in mylib::DelMyEnv (env=0x96fe50) at myenv.cpp:268
Again, any help here would be really appreciated! Any way I can help you
to help me, please let me know!!
Kind regards,
Alex
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
