Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • R Rec
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 289
    • Issues 289
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Jira
    • Jira
  • Merge requests 65
    • Merge requests 65
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LHCbLHCb
  • Rec
  • Merge requests
  • !700

Fix TrackStateProvider trackID method to only use track memory address.

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Christopher Rob Jones requested to merge TrackExtrapolators-ExtendTrackStateProviderCacheKey-2017 into 2017-patches Aug 15, 2017
  • Overview 21
  • Commits 6
  • Pipelines 0
  • Changes 1

Fixes the issue discussed in !607 (merged) by improving the way the unique track ID is computed. The previous implementation added the first and last LHCbID to the memory location. This did not always produce a unique ID, as with just the correct combination of addresses and LHCbIDs fake matches could be made.

This MR updates the code to simply use the tracks memory address. This fix is known not to be bullet proof as in theory it is possible for

  1. A track to be created.
  2. Use the tool on that track
  3. Delete that track, make a new one.
  4. Use the new track.

If at step 3 the same memory address is used, the tool will wrongly use the original cache.

In the current production code, this I am told is not done. The tool is only ever used on unchanging tracks in fixed final containers. In this scenario the memory address should be robust enough. An error is printed if the tool ever is passed a track with no parent container.

Note this fix is only needed for the rest of Run II. For Run III the whole current implementation ever needs to change completely, or no longer be used.

Edited Aug 18, 2017 by Marco Cattaneo
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: TrackExtrapolators-ExtendTrackStateProviderCacheKey-2017