[petsc-dev] XXDestroy() can be called more than once while changing type through an indirect type name

[Jed Brown]

I found this issue when changing a VECSEQ to VECCUSP. The first step goes
through without errors, but frees vec->data.

#0  0x00000000004b8033 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:776
#1  0x0000000000496c07 in VecSetType (vec=0x8f3a6b0, method=0x7fffffffe140
"cusp") at vecreg.c:46
#2  0x0000000000491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at
vector.c:1379
#3  0x0000000000492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416
#4  0x00000000005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0,
g=0x7fffffffe3a8) at dadist.c:36
#5  0x0000000000638864 in DMCreateGlobalVector (dm=0x8f2d2d0,
vec=0x7fffffffe3a8) at dm.c:363
#6  0x0000000000409079 in main (argc=7, argv=0x7fffffffe5c8) at ex47cu.cu:31


Since the function pointers were not cleared, we enter the same function
again with vec->data zero and SEGV at this line.

ierr = PetscFree(vs->array_allocated);CHKERRQ(ierr);

#0  0x00000000004b7f43 in VecDestroy_Seq (v=0x8f3a6b0) at bvec2.c:775
#1  0x0000000000496c07 in VecSetType (vec=0x8f3a6b0, method=0x10706d5
"seqcusp") at vecreg.c:46
#2  0x0000000000528246 in VecCreate_CUSP (v=0x8f3a6b0) at mpicusp.cu:238
#3  0x0000000000496cb7 in VecSetType (vec=0x8f3a6b0, method=0x7fffffffe140
"cusp") at vecreg.c:52
#4  0x0000000000491b7d in VecSetTypeFromOptions_Private (vec=0x8f3a6b0) at
vector.c:1379
#5  0x0000000000492035 in VecSetFromOptions (vec=0x8f3a6b0) at vector.c:1416
#6  0x00000000005f9af1 in DMCreateGlobalVector_DA (da=0x8f2d2d0,
g=0x7fffffffe3a8) at dadist.c:36
#7  0x0000000000638864 in DMCreateGlobalVector (dm=0x8f2d2d0,
vec=0x7fffffffe3a8) at dm.c:363
#8  0x0000000000409079 in main (argc=7, argv=0x7fffffffe5c8) at ex47cu.cu:31


The simplest fix is to wrap that call, but that semantic is a pain for the
implementations.

An alternative is to make clear vec->ops->destroy after calling it. This
seems more robust, so I'm inclined to do it.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120213/78130c43/attachment.html>