Re: Memory Managment issues

We have a templated smart pointer implementation internally, but we're 
also looking to switch to boost's implementation.  The SymbolTable Scope 
objects are pretty hairy only in-so-far as they contain circular 
references.  I believe Boost has some type of weak pointer object that 
would deal with this.  Or you could just use smart pointers within the 
my_scope map, and bare pointers for the my_outer member.

A little context: we run our application with the CRT leak checker on in 
debug.  The debugger basically locks up at the end of the application 
and reports all the leaked memory.  When we hit the synopsis code, this 
dump of leaked memory locks up the debugger for minutes, it's pretty rough.

So, typically not an issue with Boehm GC'd memory.  That library uses 
VirtualAlloc and VirtualFree to manage an internal heap, and the cleanup 
code in the library reaps the heap at the end of the process.  When that 
heap is reaped, no destructors are called, so std::string never gets a 
chance to free it's memory.  Changing the typedef in Encoding.hh makes 
it so that the std::strings allocations come from that managed heap, and 
all that memory is then cleaned up correctly by the GC library.

Hopefully that is a little more clear..  Unfortunately what is not so 
clear is why that straight forward change would cause the GC library to 
infinite loop in some cases.

Luke

Stefan Seefeld wrote:
> Luke Petre wrote:
>   
>> Howdy all.  I'm unfortunately unable to use the latest Synopsis release,
>> but a quick browse of the head revision in SVN makes it seem like the
>> problems I'm having are still around.
>>
>> There appears to be at least two memory management schemes used by
>> Synopsis.
>>
>> Synopsis::SymbolTable::Scope uses a reference counting scheme.  It
>> severely leaks memory, as the SymbolFactory does not properly release
>> references, nor does the walker, and every nested Scope creates a
>> circular reference.  This was a pretty straight forward fix, changing
>> the code to have the outer scopes hold a reference to the inner scopes,
>> and adding the proper refs and unrefs in the factory and walker.  I hope
>> I can make this change into a .patch file to submit back to the main
>> branch.
>>     
>
> You are (unfortunately) quite correct. I have been meaning to fix this
> for quite a while, but never got around to it. The SymbolTable isn't
> even used yet, in the release branch. (It just consumes memory. :-( )
>
> In the development branch, it is used, and there I'd definitely like
> to fix the way memory is managed. In fact, I have been pondering
> using boost code heavily (for smart pointers, the filesystem access,
> as well as to replace my own poor-man's implementation of a 'python C++ API'
> by boost.python). Needless to say, I'd welome any help I could get.
>
>   
>> Secondly there are the objects in the Synopsis::PTree namespace which
>> use the Boehm GC library.  This appears to be based on the OpenC++
>> parser, so I believe it generally works w/ respect to memory
>> management.  The one place I do notice a difference is in the Encoding
>> class.  In the OpenC++ parser, that class has a character buffer with a
>> fixed size.  In the Synopsis implementation it uses a std::string.  This
>> causes problems because the std::string is ultimately owned by a garbage
>> collected object, but is allocating memory from a non-garbage collected
>> heap.
>>     
>
> Why is this a problem ? You are right in that the PTree classes are descendants
> from OpenC++, but, in contrast to OpenC++, I now use the Boehm GC only and
> exclusively for PTree nodes. But, as these are ordinary C++ classes, their
> destruction will release (i.e. destruct) all member variables, no matter
> what that means. Right ?
>
> Thanks,
> 		Stefan
>
>