This bug report is the result of the initial report at https://root-forum.cern.ch/t/crashes-when-reading-a-ttree-with-a-friend.

Initially a tree t2 has a friend t1, and both are stored to a TFile, t2 with t1 stored as a friend. When opening both t2 and t1 from the file, then calling TFile::Close(), there is a crash. Most likely it is a matter of deletion order, where a tree already deleted is deleted again due to "friendliness".

Please find attached C++ and PyROOT scripts that reproduce the bug. The bug can be worked around by calling t2.RemoveFriend(t1) before calling TFile::Close().

Fixing this bug is important in a PyROOT workflow, where the branches values are accessible as attributes of the TTree. In such a case t2.GetEntry(x) also gets an entry in t1. If t1 is read from the file, both t1 and t2 branches values are available through their attributes - the most convenient way to access them in PyROOT. This behaviour does not exist in C++, thus I suspect in C++ hardly anyone opens both t1 and t2 and encounter this bug.

Encountered on ROOT 6.24.00 compiled from sources on Fedora 34.
test_friends.zip