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
Bug fix in IndexIntoFileItrImpl::firstEventEntryThisLumi #23424
Conversation
As far as I know no one has ever hit this bug. An extremely unusual set of circumstances needs to exist to hit it. First the function is only called when the LuminosityBlockAuxiliary has an invalid beginTime and the Framework is trying to fix it by getting the time from the first event in that lumi. The bug might cause it to get the wrong event and there is a remote chance this event could be from the wrong run. But for the wrong event to be selected, the lumi has to be fragmented over multiple lumi entries in the lumi TTree and that only happens after after a lumi was split over multiple files and then merged together in a noncontiguous order. It can also happen running in a mode using multiple concurrent luminosity blocks.
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23424/4965 |
please test |
The tests are being triggered in jenkins. |
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages: DataFormats/Provenance @cmsbuild, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs after it passes the integration tests. This pull request will now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
As far as I know no one has ever hit this bug.
An extremely unusual set of circumstances needs
to exist to hit it. First the function is only
called when the LuminosityBlockAuxiliary has an
invalid beginTime and the Framework is trying to
fix it by getting the time from the first event
in that lumi. The bug might cause it to get the
wrong event and there is a remote chance this event
could be from the wrong run. But for the wrong
event to be selected, the lumi has to be fragmented
over multiple lumi entries in the lumi TTree and
that only happens after after a lumi was split over
multiple files and then merged together in a noncontiguous
order. It can also happen running in a mode using
multiple concurrent luminosity blocks.