Many thanks for looking into it!
@moneta
The fix should probably solve the problem as I do not observed similar problem for other ROOT classes and the error occurred with introduction of Fitter::ObjFunction (it will be easier for me to test it on my side once it is merged in main/master branch).
@jonas
Thanks for your explanations and suggestions. It helped me to better understand several things. I noticed the warning concerning no virtual destructor (RDataFrame has no virtual destructor) but I did not know what it means (I have never observed a problem in practice).
It looks to me that in ROOT c++ methods are often virtual only if they must be implemented by user. Therefore, there are far less reasons for inheritance than they could be. It means that there are far less practical options to experiment with changed behavior of a class in ROOT already on c++ side (composition of classes does not help much here). Python provides more flexibility but, indeed, one should be aware that there might be some unforeseen effects.
There are cases where the mentioned composition of classes is indeed better option than inheritance.
The RDataFrame example (RDataFrame has no virtual destructor) is an example where one would like to only add on python side a member function to a class independently whether the C++ class has a virtual method (the same can be done in C++). Inheritance may have the advantage that it may not be necessary to modify a code base to accept the derived class (or only types need to be changes when mypy is used). Composition typically requires more changes to adapt the code base as it is necessary to distinguish between the wrapper and wrapped class. Even if a c++ non-virtual method cannot be overwritten on python side using inheritance, it can be shadowed and this can be used for intended side effects at least on python side (the parent method can be called within the python child method).