<div>I found this issue when changing a VECSEQ to VECCUSP. The first step goes through without errors, but frees vec->data.</div><div><br></div><div>#0  0x00000000004b8033 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:776</div>
<div>#1  0x0000000000496c07 in VecSetType (vec=0x8f3a6b0, method=0x7fffffffe140 "cusp") at vecreg.c:46</div><div>#2  0x0000000000491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at vector.c:1379</div><div>
#3  0x0000000000492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416</div><div>#4  0x00000000005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0, g=0x7fffffffe3a8) at dadist.c:36</div><div>#5  0x0000000000638864 in DMCreateGlobalVector (dm=0x8f2d2d0, vec=0x7fffffffe3a8) at dm.c:363</div>
<div>#6  0x0000000000409079 in main (argc=7, argv=0x7fffffffe5c8) at <a href="http://ex47cu.cu:31">ex47cu.cu:31</a></div><div><br></div><div><br></div><div>Since the function pointers were not cleared, we enter the same function again with vec->data zero and SEGV at this line.</div>
<div><br></div><div>ierr = PetscFree(vs->array_allocated);CHKERRQ(ierr);</div><div><br></div><div><div>#0  0x00000000004b7f43 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:775</div><div>#1  0x0000000000496c07 in VecSetType (vec=0x8f3a6b0, method=0x10706d5 "seqcusp") at vecreg.c:46</div>
<div>#2  0x0000000000528246 in VecCreate_CUSP (v=0x8f3a6b0) at <a href="http://mpicusp.cu:238">mpicusp.cu:238</a></div><div>#3  0x0000000000496cb7 in VecSetType (vec=0x8f3a6b0, method=0x7fffffffe140 "cusp") at vecreg.c:52</div>
<div>#4  0x0000000000491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at vector.c:1379</div><div>#5  0x0000000000492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416</div><div>#6  0x00000000005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0, g=0x7fffffffe3a8) at dadist.c:36</div>
<div>#7  0x0000000000638864 in DMCreateGlobalVector (dm=0x8f2d2d0, vec=0x7fffffffe3a8) at dm.c:363</div><div>#8  0x0000000000409079 in main (argc=7, argv=0x7fffffffe5c8) at <a href="http://ex47cu.cu:31">ex47cu.cu:31</a></div>
</div><div><br></div><div><br></div><div>The simplest fix is to wrap that call, but that semantic is a pain for the implementations.</div><div><br></div><div>An alternative is to make clear vec->ops->destroy after calling it. This seems more robust, so I'm inclined to do it.</div>
<div><br></div><div>A more radical alternative is to zero the whole vtable. Are there use cases where the user wants to change the type, but still expects some of their own MatOps to not be overwritten when changing the type?</div>