The cache in the coupling manager is currently a singleton (which is highly questionable and was a failed attempt to get thread safety). This causes the following bug: If you have more than one instance of the coupling manager (even after each other in the same program, so you create one, destroy it, create a second one), the cache is not empty because of the previous run. In https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blame/master/dumux/multidomain/freeflow/couplingmanager_staggered.hh?ref_type=heads#L520 we have ``` void bindCouplingContext_(Dune::index_constant<freeFlowMomentumIndex> domainI, const Element<freeFlowMomentumIndex>& elementI, const std::size_t eIdx) const { if (momentumCouplingContext_().empty()) { // ... fill cache } else if (eIdx != momentumCouplingContext_()[0].eIdx) { momentumCouplingContext_()[0].eIdx = eIdx; momentumCouplingContext_()[0].fvGeometry.bind(elementI); } ``` In the case create, destroy, create, the `else if` branch will segfault because fvGeometry contains a invalid pointer to a destroyed gridgeometry. In the case that two or more objects are alive, we access the gridgeometry of other instances. Could be also related to !3478 where the same issue should occur in a multithreading context. **Affected coupling managers:** * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/freeflow/couplingmanager_staggered.hh?ref_type=heads * https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/multidomain/freeflow/couplingmanager_cvfe.hh?ref_type=heads **Temporary solution** Clear the cache in `init`. This should solve the issue of multiple instances but probably doesn't solve the multithreading issue (multithreading is currently disabled though) The simplest is probably to go back to mutable caches and keep multithreading disabled.