Missing lock deep inside TClassEdit::GetNormalizedName

[pcanal]

Check duplicate issues.

• Checked for duplicates

Description

As seen in cms-sw/cmssw#47763, there seems to be missing lock inside TClassEdit::GetNormalizedName.

We see that TClingCallFunc::make_wrapper is updating the Interpreter state and the fact that the other thread is held on acquiring the lock tells us that the make_wrapper threads hold the Interpreter lock as expected.

However we observe that the other thread, which is in the process of executing GetNormalizedName is acquiring the lock during TCling::HandleNewTransaction. The fact that there is a transaction RAII in findType indicates that it also induces modification on the interpreter state.

Adding a lock acquisition right before the transaction RAII in findType should be sufficient to avoid the problem.

It might be also be meaning full to add the lock acquisition in the transaction RAII (as both are really
required for any modification of the Interpreter state) but it might be overkill as even-though the lock used by ROOT is a recursive (read/write) lock acquiring on a thread that already owns it is not completely 'free' (albeit we should probably re-measure the cost on modern hardware). So I hesitate in installing it in the transaction RAII without measuring the actual effect on performance and scalability.

Reproducer

.

ROOT version

master, v6.34.

Installation method

any

Operating system

any

Additional context

No response