parrgar21 / heekscad

Automatically exported from code.google.com/p/heekscad
Other
0 stars 0 forks source link

Undo Engine memory leaks #249

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Start HeeksCAD.
Create a cube.
Close HeeksCAD.

There is undeleted memory, that was allocated here, in
UndoEngine::GetModificationsRecursive:

        if(old_children.find(*it) == old_children.end())
        {
            //TODO, this is actually tricky, when an item is added, it may be added
in multiple places in the tree
            //we must make sure that multiple pointers get setup to this object, we
also must deep copy
            HeeksObj* copy = obj->MakeACopyWithID();
            ret.push_back(UndoEvent(EventTypeAdd,newtree,copy));
            m_oldtree.m_treemap[*it] = copy;
        }

Original issue reported on code.google.com by danhe...@gmail.com on 27 Mar 2010 at 11:11

GoogleCodeExporter commented 8 years ago
Yes, that is an interesting problem. Afaict, stuff should never be freed until
perhaps a new or open/close operation. After which it should be ok to go 
through all
the items in treemap and delete them. This is a bit trick though because the 
elements
point to other elements in weird ways. I was thinking a garbage collector would 
be
the easiest way. Like in the HeeksObj constructor it would call some system 
function,
like GC->New(this). Then the GC would have a pointer to all created objects. 
Then
when you want to clean things up, you have to get a list of alive pointers 
which can
be retrieved by descending the currently open tree, and the subtrees that 
UndoEngine
has. The stuff that needs to be deleted is then the difference between these 
lists.
Since the list is complete, there is no need to run any destructor code. Ie. no
deleting of children is necessary by the parents. This really circumvents alot 
of the
problems involved with deleting DAGs via destructor. 

Original comment by jonpry@gmail.com on 28 Mar 2010 at 7:52