[C++-sig] Memory Leaks In VS.NET 2003 With BOOST_PYTHON_MODULE

Matt mjkeyes at sbcglobal.net
Fri Oct 7 20:21:45 CEST 2005

Thanks for your reply!

I do apologize for the lack of line breaks - I'm not sure how that happened.

Anywho, I am new to boost, so please bear with me a little bit here :).  I 
realize that I could use a handle object like that to handle internal 
to the PyObject*.  However, I have modified the code, and here it is 

handle<> hInitPtr(PyImport_ImportModule( "Python.SnakeMUD" ));

handle<> hClassPtr(
    PyObject_CallMethod(hInitPtr.get(), "CreateInitialHandler", NULL));

object Handler(hClassPtr);

PythonLib::PythonInputHandler *pHandler =

//so that the returned pHandler doesn't destruct
//from the boost references above


I still get the memory leaks, and I'm not doing any IncRef's or DecRef's 
else.  I have commented out all the code, and I receive no memory leaks.

However, when I uncomment even just the first line (the hInitPtr),
I get 17 leaks.

Any advice?

Also, does the above code look reasonable?  Like I said, I'm new to boost
so I don't know if it looks clean or not.

Thanks again!

"Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com> wrote in message 
news:20051007163924.10208.qmail at web31514.mail.mud.yahoo.com...
> Your posting is missing new-lines and therefore very difficult to read.
> Over the last couple of year I ran our 50+ Boost.Python extension 
> repeatedly
> with valgrind, incl leak check. It is a very long time ago (3+ years) that 
> I
> found the last memory leak in Boost.Python. If there are still memory 
> leaks in
> Boost.Python they must be in very obscure places. I'd bet that any leaks 
> you
> are seeing are in your code. Seeing manual INCREF and DECREF in your code 
> makes
> this seem all the more likely to me. I'd consider using 
> boost::python::handle<>
> and boost::python::object to automate the reference counting.
> The key to resolving issues like your is always the same: carefully reduce 
> your
> code just until the error goes away. Then put back the last code removed 
> so
> that the error appears again. Keep reducing the code until you have a 
> minimal
> example. If the problem  is not in your code, post the minimal example to 
> this
> list, complete with information about your platform and instructions how 
> to
> compile.
> Cheers,
>        Ralf
> --- Matt <mjkeyes at sbcglobal.net> wrote:
>> Hey all,
>> i know i just posted about something else yesterday, but i have found a
>> number of memory leaks that crop up when i use BOOST_PYTHON_MODULE. 
>> Here's
>> what it looks like:
>> //NOTE SocketLib and PythonLib are two of my namespaces
>> {
> class_<PythonLib::PythonInputHandler,boost::noncopyable>("PythonInputHandler")
> .def("HandleInput",pure_virtual(&SocketLib::InputHandler<std::string>::HandleInput))
>>  .def("Enter", 
>> pure_virtual(&SocketLib::InputHandler<std::string>::Enter))
>> .def("Leave", pure_virtual(&SocketLib::InputHandler<std::string>::Leave))
>> .def("Hungup",pure_virtual(&SocketLib::InputHandler<std::string>::Hungup))
>> .def("Flooded",pure_virtual(&SocketLib::InputHandler<std::string>::Flooded))
>> .def("NoRoom",pure_virtual(&SocketLib::InputHandler<std::string>::NoRoom))
>> .def("Quit", &PythonLib::PythonInputHandler::Quit)  .def("ShutDown",
>> &PythonLib::PythonInputHandler::ShutDown)  .def("SendGlobal",
>> &PythonLib::PythonInputHandler::SendGlobal)  .def("AddInputHandler",
>> &PythonLib::PythonInputHandler::AddInputHandler)  ;}The leaks (17 of 
>> them)
>> come from the init_module_PyInputHandler call that isgenerated from this
>> macro.Here is what I call to instantiate my Python class in C++: 
>> PyObject
>> *pInit = PyImport_I!
>>  mportModule( "Python.SnakeMUD" );  if( pInit == NULL )  { 
>> PyErr_Print();
>>     //throw custom exception handling  }  //call the python method to 
>> create
>> our initial input handler  handle<> hClassPtr(PyObject_CallMethod(pInit,
>> "CreateInitialHandler",NULL));  //wrap the handle in a boost class 
>> object
>> Handler(hClassPtr);  //Get out class out of the boost class
>> PythonLib::PythonInputHandler *pHandler
>> =extract<PythonLib::PythonInputHandler*>(Handler);  //this will call
>> Py_XINCREF on the PyObject *, which will allow ourhandler to continue to
>> exist after this function exits  pHandler->SetPyObject(Handler.ptr());
>> //cleanup the module call  Py_XDECREF(pInit);  //add our new handler
>> AddInputHandler(pHandler);Nothing really fancy unless i'm doing something
>> completely stupid.  Anyadvice?Thanks in advance!Matt
> __________________________________
> Yahoo! Mail - PC Magazine Editors' Choice 2005
> http://mail.yahoo.com 

More information about the Cplusplus-sig mailing list