EinarElen
commented
1 year ago Caught another one in the Ecal veto/geometry code. When we are trying to fill the isolated hit map, we assume the list of neighbouring cells that we get from the Ecal geometry object to always have 6 entries. However, I'm seeing some events where you get a smaller number of neighbours (e.g. 4). This makes
cellNbrIds[k] = ldmx::EcalID(id.layer(), cellNbrIds[k].module(), cellNbrIds[k].cell()); do a buffer overflow.
I'm not sure if the assumption that there are always 6 neighbours is correct, if so there's another bug in some other place (e.g. the ecal geometry code). If not, the solution is to just loop over the size of the vector. @tomeichlersmith maybe you know?
// Skip hits that have a readout neighbor
// Get neighboring cell id's and try to look them up in the full cell map
// (constant speed algo.)
// these ideas are only cell/module (must ignore layer)
std::vector<ldmx::EcalID> cellNbrIds = geometry_->getNN(id);
for (int k = 0; k < 6; k++) {
// update neighbor ID to the current layer
cellNbrIds[k] = ldmx::EcalID(id.layer(), cellNbrIds[k].module(),
cellNbrIds[k].cell());
// look in cell hit map to see if it is there
if (cellMap_.find(cellNbrIds[k]) != cellMap_.end()) {
isolatedHit = std::make_pair(false, cellNbrIds[k]);
break;
}
}
tomeichlersmith
tvami
List of memory issues caught by ASAN/UBSAN and their fix-status
.size()noiseentry in calorimeter hitsDescribe the bug A missing
&in one of the helper functions in the PN DQM code meant that the particle map was copied rather than referenced which made any pointers to simparticles therein invalid after the scope of the function. This bug hasn't had any impact on the DQM output, if it did we would have seen some difference. Regardless, we should of course patch it.The culprit is here https://github.com/LDMX-Software/ldmx-sw/blob/0079ce00ff851fd427f2191c45c72d7857c37c17/DQM/include/DQM/PhotoNuclearDQM.h#L96-L110
Where the map is supposed to be passed in by const ref.
I caught this while trying to diagnose a completely different issue by running with address sanitizer enabled. I'm wondering if it would be useful to include these kinds of tools directly in our DQM jobs. At least ASAN has a minimal performance overhead. UBSAN could be interesting, but it doesn't by default kill a job if it catches something (it has some false positives) so you would only benefit from it if you read the logs.