On 21 Jun 2019, at 13:58, Lawrence Mitchell <[email protected]<mailto:[email protected]>> wrote:
Hi Vaclav, On 21 Jun 2019, at 12:14, Hapla Vaclav via petsc-dev <[email protected]<mailto:[email protected]>> wrote: VecGetValuesSection() returns pointer values obtained as follows: VecGetArray(v, &baseArray); *values = &baseArray[s->atlasOff[p]]; VecRestoreArray(v, &baseArray); It looks to me scary. VecGetArray manpage says: If the underlying vector data is not stored in a contiguous array this routine will copy the data to a contiguous array and return a pointer to that. VecRestoreArray manpage says: For any special vectors that do not store local vector data in a contiguous array, this routine will copy the data back into the underlying vector data structure from the array obtained with VecGetArray(). So I guess VecRestoreArray() is free to destroy that contiguous array, right? In this case values would point to some nonsensical location in memory. Yes, for example VecGetArray_Nest(Vec X, PetscScalar **x) { // allocate space ierr = PetscMalloc1(m,x);CHKERRQ(ierr); // copy in elided } VecRestoreArray_Nest(Vec X, PetscScalar **x) { // copy out elided ierr = PetscFree(*x);CHKERRQ(ierr); } So VecGetValuesSection is definitely not safe if using VecType == NEST. I suspect the right thing to do is to make VecGetValuesSection be a method (rather than a single VecSeq implementation). VecNest doesn't support SetValues/GetValues, so arguably it just shouldn't support SetValuesSection/GetValuesSection. Thanks, Lawrence. Sounds good. I can do that like this. Vaclav Lawrence
