GetEntry() crash in second using

Great.
So, there are three safe ways to deal with this problem.

  1. One deletes “object_of_MyClass” AFTER the tree is deleted … one of …
    1.a delete My_Tree; delete object_of_MyClass; delete pointer_to_file;
    1.b delete My_Tree; delete pointer_to_file; delete object_of_MyClass;
    1.c delete pointer_to_file; delete object_of_MyClass;

  2. One deletes “object_of_MyClass” BEFORE the tree is deleted (note: setting “object_of_MyClass = 0;”, BEFORE the tree is going to be deleted, either explicitly or implicitly, is MANDATORY) … one of …
    2.a delete object_of_MyClass; object_of_MyClass = 0; delete My_Tree; delete pointer_to_file;
    2.b delete object_of_MyClass; object_of_MyClass = 0; delete pointer_to_file;

  3. One first calls “bntrack1->SetAddress(0);” or “My_Tree->ResetBranchAddress(bntrack1);” or “My_Tree->ResetBranchAddresses();” and then the “object_of_MyClass” is no longer “associated” with the tree in any way, so one can delete it in any moment (either before or after “delete My_Tree;” and/or “delete pointer_to_file;”, and there is no need to set “object_of_MyClass = 0;”):
    http://root.cern.ch/root/html/TTree.html#TTree:ResetBranchAddress
    http://root.cern.ch/root/html/TTree.html#TTree:ResetBranchAddresses
    (Well, the descriptions of both of the above methods seem to be a bit short and there’s just that slightly worrying “Note: If any of our branches own any objects, they are deleted.”)

Note that, in any case, the “delete pointer_to_file;” call will automatically delete “My_Tree”, if it was not deleted in advance (so the “delete My_Tree;” call is usually redundant).

BTW. Maybe someone could add some notes about the ownership of objects in the “TTree” class description , in “==> Case B” at least, and in the “TTree::GetEntry” description.