[boost] [Boost-bugs] [ boost-Patches-1464421 ] Explicitly delete registered converter chains

From: SourceForge.net (noreply_at_[hidden])
Date: 2006-09-16 13:05:38

Patches item #1464421, was opened at 2006-04-04 13:54
Message generated for change (Comment added) made by david_abrahams
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1464421&group_id=7586

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Kevin J Bluck (kbluck)
Assigned to: David Abrahams (david_abrahams)
Summary: Explicitly delete registered converter chains

Initial Comment:
While working with boost.python, I've noted that
instantiating most specializations of
boost::python::extract<> results in MSVC leak reports.
My usual tactic for third-party libraries in such cases
is to suppress the CRT tracking for the affected code.
This is how I deal with the abundant "leaks" from
Python due to not calling Py_Finalize(), for example.
In this case, though, the allocations are pre-main()
and I can't get a suppression hook in ahead of it.

I realize that these aren't true leaks, and that there
is some reluctance to ferret out such situations at the
moment due to the lack of support for Py_Finalize(),
but this generates a *lot* of leak reports and makes it
very difficult to recognize true leaks. It was actually
making me consider not using extract<> at all.

I realized that was an overreaction, so instead I added
a destructor for struct
boost::python::converter::registration that explicitly
walks and deletes the singly-linked list nodes
contained therein. This resolved my current flurry of
extract<>-related leak reports.

----------------------------------------------------------------------

>Comment By: David Abrahams (david_abrahams)
Date: 2006-09-16 12:05

Message:
Logged In: YES 
user_id=52572

Accepted, but changed to factor more code into the
Boost.Python compiled library rather than inlining it in
each extension module.

I do think these are "true leaks," actually.  Py_Finalize
support would not have touched this memory.  Thanks for the
patch.  It's in the CVS HEAD (too late for 1.34.0).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1464421&group_id=7586

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Boost-bugs mailing list
Boost-bugs_at_[hidden]
https://lists.sourceforge.net/lists/listinfo/boost-bugs