Skip to content

Conversation

@sawenzel
Copy link
Collaborator

This makes it easy to valgrind the process.
It seems that despite the custom streamer, there are still sporadic segfaults when exercising DeadChannelMapCreator::loadIDCPadFlags (at least on ARM64).

@github-actions
Copy link
Contributor

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

This makes it easy to valgrind the process.
It seems that despite the custom streamer, there are still sporadic segfaults
when exercising DeadChannelMapCreator::loadIDCPadFlags (at least on ARM64).
@sawenzel sawenzel force-pushed the swenzel/caldetdebug branch from 61a65f0 to 6f5e978 Compare November 24, 2025 19:41
@sawenzel sawenzel merged commit 0fb4692 into AliceO2Group:dev Nov 24, 2025
7 of 8 checks passed
sawenzel added a commit to sawenzel/AliceO2 that referenced this pull request Nov 25, 2025
A continuation of the CalDet<TPCFlags> saga, possibly related
to https://its.cern.ch/jira/browse/O2-4671

Tests on ARM, even after deployment of the custom streamer
in AliceO2Group#14830, still showed
segfaults in TPC digitization.

With the relevant code isolated into a unit test in
AliceO2Group#14850, it was possible to
do a valgrind study. This showed Invalid reads to the mData of CalArray.

Thereafter, putting assert statements showed that we often access
CalArray<PadFlags> data slightly out of bounds - irrespective of custom
streamer or not. This then either indicates a problem in the code logic
or a problem with the calibration CCDB objects. This should clearly be
fixed.

In the meantime, this commit adds a protection against invalid accesses
and returns a trivial answer as well as an error message. This is in any
case better than undefined behaviour.

In addition, this commit introduces possibility to switch off the custom
streamer for further studies.
@sawenzel sawenzel deleted the swenzel/caldetdebug branch November 25, 2025 14:15
sawenzel added a commit that referenced this pull request Nov 25, 2025
A continuation of the CalDet<TPCFlags> saga, possibly related
to https://its.cern.ch/jira/browse/O2-4671

Tests on ARM, even after deployment of the custom streamer
in #14830, still showed
segfaults in TPC digitization.

With the relevant code isolated into a unit test in
#14850, it was possible to
do a valgrind study. This showed Invalid reads to the mData of CalArray.

Thereafter, putting assert statements showed that we often access
CalArray<PadFlags> data slightly out of bounds - irrespective of custom
streamer or not. This then either indicates a problem in the code logic
or a problem with the calibration CCDB objects. This should clearly be
fixed.

In the meantime, this commit adds a protection against invalid accesses
and returns a trivial answer as well as an error message. This is in any
case better than undefined behaviour.

In addition, this commit introduces possibility to switch off the custom
streamer for further studies.
sawenzel added a commit to sawenzel/AliceO2 that referenced this pull request Nov 26, 2025
A continuation of the CalDet<TPCFlags> saga, possibly related
to https://its.cern.ch/jira/browse/O2-4671

Tests on ARM, even after deployment of the custom streamer
in AliceO2Group#14830, still showed
segfaults in TPC digitization.

With the relevant code isolated into a unit test in
AliceO2Group#14850, it was possible to
do a valgrind study. This showed Invalid reads to the mData of CalArray.

Thereafter, putting assert statements showed that we often access
CalArray<PadFlags> data slightly out of bounds - irrespective of custom
streamer or not. This then either indicates a problem in the code logic
or a problem with the calibration CCDB objects. This should clearly be
fixed.

In the meantime, this commit adds a protection against invalid accesses
and returns a trivial answer as well as an error message. This is in any
case better than undefined behaviour.

In addition, this commit introduces possibility to switch off the custom
streamer for further studies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant