Dan Riley

Related to the first group, we are getting hits in both ASAN and UBSAN for wf 34034.0: [ASAN:](https://cmssdt.cern.ch/SDT/cgi-bin/logreader/el8_amd64_gcc12/CMSSW_15_1_ASAN_X_2025-05-09-2300/pyRelValMatrixLogs/run/34034.0_TTbar_14TeV+Run4D120/step2_TTbar_14TeV+Run4D120.log#/84-84) ``` ==2248829==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x14556f47910c at pc 0x145511e74614 bp 0x14556f478050...

[Crash observed](https://cmssdt.cern.ch/SDT/cgi-bin/logreader/el8_amd64_gcc12/CMSSW_15_1_X_2025-06-04-1100/pyRelValMatrixLogs/run/34034.0_TTbar_14TeV+Run4D120/step2_TTbar_14TeV+Run4D120.log#/151-151), probably from one of the uninitialized data instances: ``` A fatal system signal has occurred: segmentation violation The following is the call stack containing the origin of the...

> ``` > HGCDigitizer::accumulate (this=0x7fff1ef67b90, hits=..., bxCrossing=0, geom=0x7ffde61b9540, hre=0x7ffe3dbb9c80) at src/SimCalorimetry/HGCalSimProducers/plugins/HGCDigitizer.cc:671 > 671 float fireTDC = hitRefs_bx0[id].back().second; > (gdb) print id > $1 = 2350910856 > ``` `2350910856 == 0x8c200d88`,...

@jalimena where can we find the full stack trace for all threads?

> sorry i have uploaded the complete stack trace from the DAQ shifter in the issue description. Let me know if it looks incomplete. Thanks. There's a possibly relevant error...

Maybe the dynamic loader has added a call to free when a shared library uses TLS, that's always a touchy subject. Will take a look, currently puzzling over our new...

Frivolous question: what's with the `const double&` on 42-43,45. Surely those should be plain old `const double`.

> So it looks like that Sherpa based executable was built against the wrong architecture. AFAICT, the Sherpa gridpacks do not include any executable code, the Sherpa executables are all...

So that's from https://github.com/cms-sw/cmssw/blob/450f248b8d24194a8962f492f6030147fd70e9dc/IOPool/TFileAdaptor/src/TStorageFactoryFile.cc#L261-L264 One of the goals of https://github.com/cms-sw/cmssw/pull/48088 (and my changes as well) is to always pass in a tree to `TFile::{G,S}etCacheRead()`, so I guess the nullptr call...

> The lock is taken too late. The lock should happen before the call to `edm::PoolSource::readLuminosityBlock_`. This points to a concurrency problem in dealing with concurrent LuminosityBlocks. So we have...