-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Do not call TTree cache after an exception happens #12658
Do not call TTree cache after an exception happens #12658
Conversation
Since TTree is not exception safe, we must avoid calling TTree methods after we have had an exception thrown through TTree. Normally this happens when one thread throws an exception while another thread is waiting to access the same TTree. This should avoid crashes seen in the Tier 0.
A new Pull Request was created by @Dr15Jones (Chris Jones) for CMSSW_8_0_X. It involves the following packages: IOPool/Input @cmsbuild, @smuzaffar, @Dr15Jones, @davidlange6 can you please review it and eventually sign? Thanks. Following commands in first line of a comment are recognized
|
please test |
+1 |
The tests are being triggered in jenkins. |
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_0_X IBs after it passes the integration tests. This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
//If a fatal exception happens we need to make a copy so we can | ||
// rethrow that exception on other threads. This avoids TTree | ||
// non-exception safety problems on later calls to TTree. | ||
mutable std::unique_ptr<Exception> lastException_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this marked as mutable? Is assignment to std::unique_ptr
atomic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All calls to RootDelayedReader are already serialized by the framework.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sigh. I guess that'll do for now then.
This covers when we are pulling products from the file. Are there any concerns about interacting with trees at startup? I'd guess not, as file opens should be in a single-threaded context. |
-1 >> Compiling edm plugin /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/JetIDProducer.cc >> Compiling edm plugin /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/MVAJetPuIdProducer.cc >> Compiling edm plugin /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/NjettinessAdder.cc >> Compiling edm plugin /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/PUFilter.cc /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/NjettinessAdder.cc: In constructor 'NjettinessAdder::NjettinessAdder(const edm::ParameterSet&)': /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/NjettinessAdder.cc:30:3: error: 'OriginalGeometricMeasure' is not a member of 'fastjet::contrib' fastjet::contrib::OriginalGeometricMeasure geometricMeasure (beta_);// changed in 1.020 ^ /tmp/cmsbuild/workspace/ib-any-integration/CMSSW_8_0_X_2015-12-02-2300/src/RecoJets/JetProducers/plugins/NjettinessAdder.cc:38:52: error: 'geometricMeasure' was not declared in this scope case OriginalGeometricMeasure : measureDef = &geometricMeasure; break;// changed in 1.020 ^ you can see the results of the tests here: The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
The test failure has nothing to do with this pull request and is from the broken IB. |
…tion Do not call TTree cache after an exception happens
Since TTree is not exception safe, we must avoid calling TTree methods after we have had an exception thrown through TTree. Normally this happens when one thread throws an exception while another thread is waiting to access the same TTree.
This should avoid crashes seen in the Tier 0.