Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TBranchElement: no drilling through new members. #9927

Merged
merged 3 commits into from
Feb 18, 2022

Conversation

pcanal
Copy link
Member

@pcanal pcanal commented Feb 18, 2022

See #9913

This resolved the problem seen at: cms-sw/cmssw#36908 (comment)
and fix #9899.

The problem is the rules are applied to a data member nested inside an object nested inside
an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL,
since it is a new member compared to the layout on file, none of the objects; from the new
member down to the object on which the rules need to be run) are actually streamed and the
code gathering the information to run the rule got a bit lost ; it is likely (I am checking
as we speak) that in previous release the rule was not even attempted to be run ... which
might actually be the desired behavior in this specific case.

The solution is to have GatherArtificialElements stop drilling through data members which
are not stored in the existing TTree

(thanks valgrind for pointing this out)
This resolved the problem seen at: cms-sw/cmssw#36908 (comment)
and fix root-project#9899.

The problem is the rules are applied to a data member nested inside an object nested inside
an STL collection that is a new data member of the class reco::HaloClusterCandidateHCAL,
since it is a new member compared to the layout on file, none of the objects; from the new
member down to the object on which the rules need to be run) are actually streamed and the
code gathering the information to run the rule got a bit lost ; it is likely (I am checking
as we speak) that in previous release the rule was not even attempted to be run ... which
might actually be the desired behavior in this specific case.

The solution is to have GatherArtificialElements stop drilling through data members which
are not stored in the existing TTree.
@pcanal pcanal requested a review from Axel-Naumann as a code owner February 18, 2022 04:06
@pcanal pcanal self-assigned this Feb 18, 2022
@phsft-bot
Copy link
Collaborator

Starting build on ROOT-debian10-i386/cxx14, ROOT-performance-centos8-multicore/default, ROOT-ubuntu16/nortcxxmod, ROOT-ubuntu2004/soversion, mac1015/python3, mac11/cxx17, windows10/cxx14
How to customize builds

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TTree incorrectly run I/O customization rules on "new" data members.
2 participants