[petsc-dev] [petsc-maint #95566] petscstack resetting
Daniel Lowell
redratio1 at gmail.com
Thu Nov 3 17:20:06 CDT 2011
Thanks Barry!
There is really something about the human mind and preconceptions... Since
I could trace it down only so far I assumed the issue was outside my code.
Turns out I was missing exactly 1 PetscFunctionBegin! that is all it took.
Thanks again.
Daniel Lowell
On Thu, Nov 3, 2011 at 5:01 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> The stack is pushed on PetscFunctionBegin; and popped on
> PetscFunctionReturn(0); so if the stack is smaller than it should be that
> means that there is a PetscFunctionReturn() without its partner
> PetscFunctionBegin;
>
> Unfortunately I cannot see from your stack frames where the problem is?
> Maybe your "custom gpu vector" is missing a begin somewhere?
>
>
> Barry
>
> On Nov 3, 2011, at 4:54 PM, Daniel Lowell wrote:
>
> > Hello all,
> >
> >
> > In working with petsc-dev in the debugger I have found that petscstack
> > popped empty before PETSc returns to the main of the program; i.e.,
> > prematurely emptied.
> >
> > My version:
> > PETSc Dev-Version 3.2.3
> >
> >
> > Okay I'll just walk to through the debug output as I found the issue,
> then
> > show where specifically it is being consumed.
> > I am running src/snes/examples/tutorials/ex14.
> >
> > Using command:
> > gdb --args ./ex14 -pc_type none -vec_type seqgpu -mat_no_inode
> >
> > That Vec type is a custom gpu vector.
> >
> >
> >
> > First I break at SNESSolve:
> >
> >
> > Breakpoint 3, SNESSolve (snes=0x8457cb0, b=0x0, x=0x8472a70) at
> snes.c:2673
> > 2673 for (grid=0; grid<snes->gridsequence; grid++) {ierr =
> >
> PetscViewerASCIIPushTab(PETSC_VIEWER_STDOUT_(((PetscObject)snes)->comm));CHKERRQ(ierr);}
> >
> >
> > I take a look at the petscstack:
> >
> > (gdb) set $ii=0
> > (gdb) p petscstack->function[$ii++]
> > $35 = 0x1083450 "SNESSolve"
> >
> >
> > Yup, it is in there:
> >
> >
> > (gdb) bt
> > #0 SNESSolve (snes=0x8457cb0, b=0x0, x=0x8472a70) at snes.c:2673
> > #1 0x0000000000407765 in main (argc=6, argv=0x7fffffffdfb8) at
> ex14.c:165
> >
> > Also it matches the trace.
> >
> > Next I break at SNESSolve_LS:
> >
> >
> > Breakpoint 4, SNESSolve_LS (snes=0x8457cb0) at ls.c:142
> > 142 SNES_LS *neP = (SNES_LS*)snes->data;
> >
> >
> >
> > Check the stack again:
> >
> >
> > (gdb) set $ii=0
> > (gdb) p petscstack->function[$ii++]
> > $36 = 0x0
> > (gdb)
> > $37 = 0x0
> >
> >
> > What happened? Stack is now empty!
> >
> >
> >
> > (gdb) bt
> > #0 SNESSolve_LS (snes=0x8457cb0) at ls.c:142
> > #1 0x0000000000612df5 in SNESSolve (snes=0x8457cb0, b=0x0, x=0x8472a70)
> at
> > snes.c:2695
> > #2 0x0000000000407765 in main (argc=6, argv=0x7fffffffdfb8) at
> ex14.c:165
> > (gdb) c
> > Continuing.
> >
> >
> > Backtrace shows of course two PETSc frames.
> >
> >
> >
> >
> >
> ...........................................................................
> > Something is not right. I've tracked it down to something going on here.
> >
> >
> >
> >
> > Breakpoint 16, VecSetType (vec=0x85aea00, method=0x1072069 "seq") at
> > vecreg.c:55
> > 55 PetscFunctionReturn(0);
> > (gdb) bt
> > #0 VecSetType (vec=0x85aea00, method=0x1072069 "seq") at vecreg.c:55
> > #1 0x00000000004ca5e0 in VecCreate_Standard (v=0x85aea00) at pbvec.c:265
> > #2 0x000000000048d3a4 in VecSetType (vec=0x85aea00, method=0x8468d70
> > "standard") at vecreg.c:53
> > #3 0x00000000005b7571 in DMCreateGlobalVector_DA (da=0x8465cf0,
> > g=0x8457ee8) at dadist.c:35
> > #4 0x00000000005f2c5f in DMCreateGlobalVector (dm=0x8465cf0,
> > vec=0x8457ee8) at dm.c:303
> > #5 0x00000000005b7017 in VecDuplicate_MPI_DA (g=0x8472a70, gg=0x8457ee8)
> > at dadist.c:17
> > #6 0x0000000000481240 in VecDuplicate (v=0x8472a70, newv=0x8457ee8) at
> > vector.c:541
> > #7 0x0000000000609a58 in SNESSetUp (snes=0x8457cb0) at snes.c:1599
> > #8 0x0000000000612b67 in SNESSolve (snes=0x8457cb0, b=0x0, x=0x8472a70)
> at
> > snes.c:2685
> > #9 0x0000000000407765 in main (argc=6, argv=0x7fffffffdfb8) at
> ex14.c:165
> > (gdb) p petscstack->currentsize
> > $160 = 9
> > (gdb) n
> > 56 }
> > (gdb)
> > VecCreate_Standard (v=0x85aea00) at pbvec.c:269
> > 269 PetscFunctionReturn(0);
> > (gdb) p petscstack->currentsize
> > $161 = 8
> > (gdb) n
> > 270 }
> > (gdb) p petscstack->currentsize
> > $162 = 7
> > (gdb) n
> >
> >
> >
> >
> > The stack is being consumed...
> >
> >
> >
> > Breakpoint 16, VecSetType (vec=0x85aea00, method=0x8468d70 "standard") at
> > vecreg.c:55
> > 55 PetscFunctionReturn(0);
> > (gdb) p petscstack->currentsize
> > $163 = 7
> > (gdb) n
> > 56 }
> > (gdb) p petscstack->currentsize
> > $164 = 6
> > (gdb) n
> > DMCreateGlobalVector_DA (da=0x8465cf0, g=0x8457ee8) at dadist.c:36
> > 36 ierr = VecSetFromOptions(*g);CHKERRQ(ierr);
> > (gdb) p petscstack->currentsize
> > $165 = 6
> > (gdb) n
> >
> > Breakpoint 16, VecSetType (vec=0x85aea00, method=0x7fffffffc9e0 "seqgpu")
> > at vecreg.c:55
> > 55 PetscFunctionReturn(0);
> > (gdb) p petscstack->currentsize
> > $166 = 5
> > (gdb) n
> > 56 }
> > (gdb) p petscstack->currentsize
> > $167 = 4
> > (gdb) n
> > VecSetTypeFromOptions_Private (vec=0x85aea00) at vector.c:1382
> > 1382 PetscFunctionReturn(0);
> > (gdb) p petscstack->currentsize
> > $168 = 4
> > (gdb) n
> > 1383 }
> > (gdb) p petscstack->currentsize
> > $169 = 3
> > (gdb) n
> > VecSetFromOptions (vec=0x85aea00) at vector.c:1418
> > 1418 if (vec->ops->setfromoptions) {
> > (gdb) p petscstack->currentsize
> > $170 = 3
> > (gdb) n
> > 1423 ierr =
> > PetscObjectProcessOptionsHandlers((PetscObject)vec);CHKERRQ(ierr);
> > (gdb) p petscstack->currentsize
> > $171 = 3
> > (gdb) n
> > 1424 ierr = PetscOptionsEnd();CHKERRQ(ierr);
> > (gdb)
> > 1413 ierr = PetscObjectOptionsBegin((PetscObject)vec);CHKERRQ(ierr);
> > (gdb)
> > 1424 ierr = PetscOptionsEnd();CHKERRQ(ierr);
> > (gdb)
> > 1426 ierr = VecViewFromOptions(vec,
> > ((PetscObject)vec)->name);CHKERRQ(ierr);
> > (gdb)
> > 1427 PetscFunctionReturn(0);
> > (gdb)
> > 1428 }
> > (gdb)
> > DMCreateGlobalVector_DA (da=0x8465cf0, g=0x8457ee8) at dadist.c:37
> > 37 ierr =
> > PetscObjectCompose((PetscObject)*g,"DM",(PetscObject)da);CHKERRQ(ierr);
> > (gdb) p petscstack->currentsize
> > $172 = 2
> > (gdb) n
> > 38 ierr = VecSetLocalToGlobalMapping(*g,da->ltogmap);CHKERRQ(ierr);
> > (gdb)
> > 39 ierr =
> > VecSetLocalToGlobalMappingBlock(*g,da->ltogmapb);CHKERRQ(ierr);
> > (gdb)
> > 40 ierr = VecSetBlockSize(*g,dd->w);CHKERRQ(ierr);
> > (gdb)
> > 41 ierr =
> >
> VecSetOperation(*g,VECOP_VIEW,(void(*)(void))VecView_MPI_DA);CHKERRQ(ierr);
> > (gdb)
> > 42 ierr =
> >
> VecSetOperation(*g,VECOP_LOAD,(void(*)(void))VecLoad_Default_DA);CHKERRQ(ierr);
> > (gdb)
> > 43 ierr =
> >
> VecSetOperation(*g,VECOP_DUPLICATE,(void(*)(void))VecDuplicate_MPI_DA);CHKERRQ(ierr);
> > (gdb)
> > 44 PetscFunctionReturn(0);
> > (gdb)
> > 45 }
> > (gdb) p petscstack->currentsize
> > $173 = 1
> > (gdb) n
> > DMCreateGlobalVector (dm=0x8465cf0, vec=0x8457ee8) at dm.c:304
> > 304 PetscFunctionReturn(0);
> > (gdb) p petscstack->currentsize
> > $174 = 1
> > (gdb) n
> > 305 }
> > (gdb) p petscstack->currentsize
> > $175 = 0
> >
> >
> >
> > The petscstack is fully used up at this point, however...
> >
> > (gdb) bt
> > #0 DMCreateGlobalVector (dm=0x8465cf0, vec=0x8457ee8) at dm.c:305
> > #1 0x00000000005b7017 in VecDuplicate_MPI_DA (g=0x8472a70, gg=0x8457ee8)
> > at dadist.c:17
> > #2 0x0000000000481240 in VecDuplicate (v=0x8472a70, newv=0x8457ee8) at
> > vector.c:541
> > #3 0x0000000000609a58 in SNESSetUp (snes=0x8457cb0) at snes.c:1599
> > #4 0x0000000000612b67 in SNESSolve (snes=0x8457cb0, b=0x0, x=0x8472a70)
> at
> > snes.c:2685
> > #5 0x0000000000407765 in main (argc=6, argv=0x7fffffffdfb8) at
> ex14.c:165
> > (gdb)
> >
> >
> >
> >
> >
> >
> > At first I thought it was due to the fact I modified ex14 at line 108 and
> > inserted:
> > ierr = VecSetFromOptions(x);CHKERRQ(ierr);
> >
> > And th petsc stack is being consumed prematurely here just as it is
> above.
> > However since this is also happening in SNESSolve...
> >
> > VecCUSP and VecPThreads I believe are activated through configuration
> > options(i.e., preprocessing) so I'm not sure if anyone has hit this
> issue.
> > The gpu vector type I'm implementing is activated as command line option.
> > Has anyone else encountered this issue?
> >
> > Any insight would be appreciated.
> >
> >
> >
> >
> > Thanks,
> >
> > Daniel Lowell
> >
>
>
--
Daniel Lowell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111103/6831dfa1/attachment.html>
More information about the petsc-dev
mailing list