Slava Krutelyov
Slava Krutelyov
> the last crash stack backtrace is different; one of the last points is `std::vector::~vector()` I don't think there's anything exotic (like concurrency-related) in the `mkfit::TrackCand` type and the vector...
> for `aarch64` with a similar crash on `MkFitOutputConverter`: sorry, how is this similar? the stack points to `Module: TrackProducer:highPtTripletStepTracks (crashed)`
@cms-sw/hlt-l2 @cms-sw/reconstruction-l2 are there any pending comments still? Please check/clarify. Thank you.
@rappoccio @antoniovilela the PR is fully signed for two days now. What is the reason to further delay merging? Please clarify. Thank you.
> it seems plausible that then the problem originates here: > > [cmssw/TrackingTools/KalmanUpdators/src/KFUpdator.cc](https://github.com/cms-sw/cmssw/blob/32dc27774b47d882609be07a885b060b9398d96e/TrackingTools/KalmanUpdators/src/KFUpdator.cc#L170-L173) it's not in the crash stack. Do you mean the preceding LogError? For a fix, instead of...
> ```diff > @@ -299,6 +299,11 @@ std::vector StandAloneMuonFilter::findBestMeasurements(co > ``` `StandAloneMuonFilter::refit` is missing checks of validity, although it does check the empty output from the `findBestMeasurements` in lieu of...
on a second thought, I'm not really against the `edm::LogError` in the ForwardDetLayers; it's still more appropriate than a crash. The hope from going upstream would be to see if...
@cms-sw/reconstruction-l2 if you are OK, perhaps this issue can be signed so that the repository can actually be created. Thank you.
@cmsbuild please test