Closed c-dilks closed 8 months ago
Not clear why the valgrind
check fails: https://github.com/eic/epic-analysis/actions/runs/7303577945/job/19904567989?pr=290#step:6:148
Let's just disable it in the CI. This job doesn't fail if leaks are detected, and it would be better to use an address sanitizer anyway.
macro/ci/valgrind_check.sh
remains available in case valgrind
(with the suggested suppressions) is still wanted.
Comparsion jobs just crash... @Gregtom3 any idea why?
https://github.com/eic/epic-analysis/pull/290/checks#step:6:167
seems like the crash happens here: https://github.com/eic/epic-analysis/blob/37112694ee7daa0ec44a2a71a48323348a78f987/macro/ci/comparator.C#L92-L94
It's not happy with
std::vector<HistosDAG*> Dext
I'm not sure what the problem is here... the inheritance is:
HistosDAG : Adage<Histos> : DAG : TObject
So ultimately this is a vector of TObject
pointers. Creating std::vector<TObject*>
causes no crash, so the problem may be in one of the derived classes.
Some more ideas toward a solution:
comparator.C
std::vector<HistosDAG>
(vector of objects, not pointers)~std::vector<std::unique_ptr<HistosDAG>>
This PR got a bit side tracked trying to resolve a separate issue. I've opened that issue at https://github.com/eic/epic-analysis/issues/291 since I was unsuccessful in fixing it here.
This PR is ready, since it at least fixes the $PYTHIA8
and valgrind
CI issues. (@Gregtom3 @cpecar the comparison jobs will fail, but you should have the power to force-merge this; if not, just approve it (if you think it's okay!) and I can force the merge).
Briefly, what does this PR introduce?
Address CI failures in https://github.com/eic/epic-analysis/pull/289
If Pythia8 libs are in the system default location, there's no need for the (nowadays unbound)
$PYTHIA8
environment variable.What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
no
Does this PR change default behavior?
no