Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • athena athena
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Jira
    • Jira
  • Merge requests 139
    • Merge requests 139
  • Deployments
    • Deployments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Commits
Collapse sidebar
  • atlas
  • athenaathena
  • Merge requests
  • !53544

RootUtils: Workaround for root TClassTable locking issue.

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Scott Snyder requested to merge ssnyder/athena:lock2.RootUtils-20220520 into master May 20, 2022
  • Overview 3
  • Commits 1
  • Pipelines 1
  • Changes 2

TClassTable is an internal ROOT structure used to hold information about all classes known to ROOT, whether or not full dictionary information has been built. This is effectively a singleton; however, TClassTable itself contains no locking. Rather, it relies on the caller already having acquired the ROOT core mutex. In most cases, that happens. However, when a shared object containing ROOT dictionaries is loaded, calls are made to TClassTable to record the classes present in that dictionary. But, in that case, the core mutex is not acquired, resulting in a potential race.

This would be best addressed inside ROOT, by acquiring the lock in TGenericClassInfo::Init. As a temporary workaround, however, use the existing DSO hooks to acquire the root lock around all shared library loads.

cf ATR-25049.

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: lock2.RootUtils-20220520