Hi Matt, Attached is a folder containing the code and a sample mesh.
Thanks for the help. - Garnet On Wed, Aug 28, 2013 at 11:43 AM, Matthew Knepley <[email protected]> wrote: > On Wed, Aug 28, 2013 at 12:52 PM, Garnet Vaz <[email protected]> wrote: > >> Thanks Jed. I did as you told and the code finally crashes on both >> builds. I installed the 3.4.2 release now. >> >> The problem now seems to come from DMPlexDistribute(). I have two >> versions to load the mesh. One creates a mesh using Triangle >> from PETSc and the other loads a mesh using DMPlexCreateFromCellList(). >> >> Is the following piece of code for creating a mesh using Triangle right? >> > > Okay, something is really very wrong here. It is calling > EnlargePartition(), but for > that path to be taken, you have to trip and earlier exception. It should > not be possible > to call it. So I think you have memory corruption somewhere. > > Can you send a sample code we can run? > > Thanks, > > Matt > > >> ierr = DMPlexCreateBoxMesh(comm,2,interpolate,&user->dm);CHKERRQ(ierr); >> if (user->dm) { >> DM refinedMesh = NULL; >> DM distributedMesh = NULL; >> ierr = >> DMPlexSetRefinementLimit(user->dm,refinementLimit);CHKERRQ(ierr); >> ierr = DMRefine(user->dm,PETSC_COMM_WORLD,&refinedMesh);CHKERRQ(ierr); >> if (refinedMesh) { >> ierr = DMDestroy(&user->dm);CHKERRQ(ierr); >> user->dm = refinedMesh; >> } >> ierr = >> DMPlexDistribute(user->dm,"chaco",1,&distributedMesh);CHKERRQ(ierr); >> if (distributedMesh) { >> ierr = DMDestroy(&user->dm);CHKERRQ(ierr); >> user->dm = distributedMesh; >> } >> } >> >> Using gdb, the code gives a SEGV during distribution. The backtrace when >> the fault >> occurs points to an invalid pointer for ISGetIndices(). Attached is a >> screenshot of the >> gdb backtrace. >> Do I need to set up some index set here? >> >> The same error occurs when trying to distribute a mesh using >> DMPlexCreateFromCellList(). >> >> Thanks for the help. >> >> >> - >> Garnet >> >> >> On Wed, Aug 28, 2013 at 6:38 AM, Jed Brown <[email protected]> wrote: >> >>> Garnet Vaz <[email protected]> writes: >>> >>> > Hi, >>> > >>> > I just rebuilt PETSc on both my laptop and my desktop. >>> > On both machines the output of >grep GIT configure.log >>> > Defined "VERSION_GIT" to >>> > ""d8f7425765acda418e23a679c25fd616d9da8153"" >>> > Defined "VERSION_DATE_GIT" to ""2013-08-27 10:05:35 -0500"" >>> >>> Thanks for the report. Matt just merged a bunch of DMPlex-related >>> branches (about 60 commits in total). Can you 'git pull && make' to let >>> us know if the problem is still there? (It may not fix the issue, but >>> at least we'll be debugging current code.) >>> >>> When dealing with debug vs. optimized issues, it's useful to configure >>> --with-debugging=0 COPTFLAGS='-O2 -g'. This allows valgrind to include >>> line numbers, but it (usually!) does not affect whether the error >>> occurs. >>> >>> > My code runs on both machines in the debug build without causing >>> > any problems. When I try to run the optimized build, the code crashes >>> > with a SEGV fault on my laptop but not on the desktop. I have built >>> > PETSc using the same configure options. >>> > >>> > I have attached the outputs of valgrind for both my laptop/desktop for >>> > both the debug/opt builds. How can I figure out what differences are >>> > causing the errors in one case and not the other? >>> >>> It looks like an uninitialized variable. Debug mode often ends up >>> initializing local variables where as optimized leaves junk in them. >>> Stack allocation alignment/padding is also often different. >>> Unfortunately, valgrind is less powerful for debugging stack corruption, >>> so the uninitialized warning is usually the best you get. >>> >> >> >> >> -- >> Regards, >> Garnet >> > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > -- Regards, Garnet
sample.tar.gz
Description: GNU Zip compressed data
