Skip to content

Conversation

@ChSonnabend
Copy link
Contributor

This avoids index overflows encountered in my AO2Ds

@github-actions
Copy link

O2 linter results: ❌ 0 errors, ⚠️ 0 warnings, 🔕 0 disabled

@github-actions github-actions bot changed the title Adding overflow short-circuit [Common] Adding overflow short-circuit Oct 10, 2025
@ChSonnabend
Copy link
Contributor Author

Ping @fgrosa
This avoids my seg-faults entirely. Not sure why they happen and didn't investigate further, maybe you have an idea?

@ChSonnabend
Copy link
Contributor Author

@fgrosa Please let me know if this is fine, then we could merge. The CI failures seem unrelated.

@fgrosa
Copy link
Collaborator

fgrosa commented Oct 20, 2025

Hi @rahulverma012 I think that this fixes the longstanding issue with trackQA indices, can you check if it's fine?

@ChSonnabend
Copy link
Contributor Author

Hi @rahulverma012 I think that this fixes the longstanding issue with trackQA indices, can you check if it's fine?

At least its a workaround for now avoiding segfaults. Ultimately its better to find the root cause why the indices can go out of bounds, but I'm no expert here (and as mentioned before, I didn't investigate any further...). Once Rahul agrees maybe we could have it merged @ddobrigk ?
(CI error seems unrelated)

@ChSonnabend
Copy link
Contributor Author

@rahulverma012 Please give us a reaction, if possible I would like to get this merged and close this PR

@rahulverma012
Copy link
Contributor

Hi @ChSonnabend, @fgrosa,
I've reviewed your changes, and they are correct — the task now works as intended.
@ddobrigk, could you please approve the PR?

Thank you

@rahulverma012
Copy link
Contributor

Hi @rahulverma012 I think that this fixes the longstanding issue with trackQA indices, can you check if it's fine?

At least its a workaround for now avoiding segfaults. Ultimately its better to find the root cause why the indices can go out of bounds, but I'm no expert here (and as mentioned before, I didn't investigate any further...). Once Rahul agrees maybe we could have it merged @ddobrigk ? (CI error seems unrelated)

To explain:
Let's say the Tracks Table has size N and the TrackQA Table has size M.
Initially, the task stores the global indices from the TrackQA table into an indexList vector.
Then, it iterates over the Tracks table, checking whether each track exists in indexList.
If it does, it stores the corresponding value in a new table.If not, it assigns -1.
A while loop was used to keep the lookup bounded within N + M iterations.
However, when all M entries from indexList had been processed, and there were still tracks remaining without assignment, the loop would continue and eventually access beyond the bounds of the vector—causing a segfault.
Thanks to your out-of-bounds check, this issue is now avoided, and the behavior is now as intended—no crashes.

Thank you

@ChSonnabend
Copy link
Contributor Author

Hi @rahulverma012 I think that this fixes the longstanding issue with trackQA indices, can you check if it's fine?

At least its a workaround for now avoiding segfaults. Ultimately its better to find the root cause why the indices can go out of bounds, but I'm no expert here (and as mentioned before, I didn't investigate any further...). Once Rahul agrees maybe we could have it merged @ddobrigk ? (CI error seems unrelated)

To explain: Let's say the Tracks Table has size N and the TrackQA Table has size M. Initially, the task stores the global indices from the TrackQA table into an indexList vector. Then, it iterates over the Tracks table, checking whether each track exists in indexList. If it does, it stores the corresponding value in a new table.If not, it assigns -1. A while loop was used to keep the lookup bounded within N + M iterations. However, when all M entries from indexList had been processed, and there were still tracks remaining without assignment, the loop would continue and eventually access beyond the bounds of the vector—causing a segfault. Thanks to your out-of-bounds check, this issue is now avoided, and the behavior is now as intended—no crashes.

Thank you

Excellent, thank you! This was my suspicion and the reason why I implemented it in this way. I was just not sure if there was a smarter away to avoid this workaround. But from what I understand the size of the two tables will realistically always mismatch. In this case this is probably the best possible solution. @ddobrigk ready for the merge from my side then too 👍

@ChSonnabend
Copy link
Contributor Author

Hi @ktf can we merge this please?

@ktf ktf merged commit f25f9e9 into AliceO2Group:master Oct 27, 2025
11 of 12 checks passed
@ktf
Copy link
Member

ktf commented Oct 27, 2025

Merging. The whole code could probably use some cleanup and done in 2 N logM rather than NxM, e.g. by exploiting the fact that the list can be presorted. The code also misses some "reserve" statement, AFAICT.

ThePhDane pushed a commit to ThePhDane/O2Physics that referenced this pull request Nov 3, 2025
lmattei01 pushed a commit to lmattei01/O2Physics that referenced this pull request Dec 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Development

Successfully merging this pull request may close these issues.

4 participants