Closed stephankramer closed 3 years ago
@angus-g : after discussing this with @drhodrid this morning and having another look, I think the issue is that if a detector (so not a particle) is moved between processes (due to parallel mesh adaptivity) it doesn't always allocate the %attributes
array. This array is allocated to zero size in create_single_detector
, but for instance lines 2049-2050 of Zoltan_integraion.F90 a detector is created without its %attributes being allocated neither in the allocate
or in the unpack_detector
call. Then when this detector needs to move again, in zoltan_cb_pack_fields
it expects every detector (and particle) to have an allocated %attributes
because on line 1084 of Zoltan_callbacks.F90
it checks for the size of the array, which of course is undefined if it is not allocated.
I'm not entirely sure where the most logical place is to put the allocate - since you're more familiar with the code would you mind having a look? To reproduce you can run the test in the fluidity/actions:bionic-9c94ec79a1e4dcc68f1c82b481b36571f9f11d1d docker container
This test segfaults in the last adapt when trying to pack data for detector migration in zoltan Backtrace:
which is
Looks like the lhs is fine - it's actually the
detector%attributes
that is unallocated (print *, allocateddetector%attributes
print F). This is also flagged by valgrind first in line 56 of Zoltan_detectors.F90:So the detector appears associated, but asking for the size of
detector%attributes
is flagged by valgrind as using uninitialised memory.