From: Andrew D. <and...@gm...> - 2013-06-06 14:45:00
|
Hi, I am trying to solve a nonlinear PDE with libMesh. I have installed libmesh with petsc enabled and I have written a simple "hello world" program that links with the library mesh_dbg, which complies fine. However, at runtime I get the message: dyld: Symbol not found: _DM_CLASSID Referenced from: /usr/local/lib/libmesh_dbg.0.dylib Expected in: flat namespace in /usr/local/lib/libmesh_dbg.0.dylib Trace/BPT trap: 5 Does anyone know what this means? and/or how to fix this problem? Thanks! Andy |
From: John P. <jwp...@gm...> - 2013-06-06 15:20:21
|
On Thu, Jun 6, 2013 at 8:44 AM, Andrew Davis <and...@gm...> wrote: > Hi, > > I am trying to solve a nonlinear PDE with libMesh. I have installed > libmesh with petsc enabled and I have written a simple "hello world" > program that links with the library mesh_dbg, which complies fine. > However, at runtime I get the message: > > dyld: Symbol not found: _DM_CLASSID > Referenced from: /usr/local/lib/libmesh_dbg.0.dylib > Expected in: flat namespace > in /usr/local/lib/libmesh_dbg.0.dylib > Trace/BPT trap: 5 Might be a PETSc DM thing? What does your Makefile look like? -- John |
From: Andrew D. <and...@gm...> - 2013-06-06 16:09:26
|
Hi, I'm using cmake to generate the Makefile so it is difficult to interpret, but you are quite right about the PETSc DM issue; I completely forgot to tell cmake where the PETSc libraries live. I added this to CMakeLists.txt and re-complied my code and now I get this error (at runtime) when I initialize libMesh: [-1]PETSC ERROR: --------------------- Error Message ------------------------------------ [-1]PETSC ERROR: No support for this operation for this object type! [-1]PETSC ERROR: You cannot set PETSC_COMM_WORLD if you have not initialized MPI first! [-1]PETSC ERROR: ------------------------------------------------------------------------ [-1]PETSC ERROR: [-1]PETSC ERROR: See docs/changes/index.html for recent updates. [-1]PETSC ERROR: See docs/faq.html for hints about trouble shooting. [-1]PETSC ERROR: See docs/index.html for manual pages. [-1]PETSC ERROR: ------------------------------------------------------------------------ [-1]PETSC ERROR: Libraries linked from /Users/Andy/software/petsc/arch-darwin-c-debug/lib [-1]PETSC ERROR: Configure run at Wed Jun 5 17:06:06 2013 [-1]PETSC ERROR: Configure options --with-cc=gcc --with-fc=gfortran --download-f-blas-lapack --download-mpich [-1]PETSC ERROR: ------------------------------------------------------------------------ [-1]PETSC ERROR: PetscInitialize() line 676 in /Users/Andy/software/petsc/src/sys/objects/pinit.c [-1]PETSC ERROR: LibMeshInit() line 457 in "unknowndirectory/"src/base/libmesh.C Could this be because I had to add the --disable-mpi flag to libMesh when I configured? If I don't disable MPI when I configure libMesh the compiler complains (at compile time): petsc/arch-darwin-c-debug/include/mpicxx.h:2723:34: error: declaration of C function 'void Parmetis::MPI::Init(int&, char**&)' conflicts with extern void Init(int &, char **& ); Thanks for your help, Andy On Thu, Jun 6, 2013 at 11:19 AM, John Peterson <jwp...@gm...> wrote: > On Thu, Jun 6, 2013 at 8:44 AM, Andrew Davis <and...@gm...> wrote: > > Hi, > > > > I am trying to solve a nonlinear PDE with libMesh. I have installed > > libmesh with petsc enabled and I have written a simple "hello world" > > program that links with the library mesh_dbg, which complies fine. > > However, at runtime I get the message: > > > > dyld: Symbol not found: _DM_CLASSID > > Referenced from: /usr/local/lib/libmesh_dbg.0.dylib > > Expected in: flat namespace > > in /usr/local/lib/libmesh_dbg.0.dylib > > Trace/BPT trap: 5 > > Might be a PETSc DM thing? > > What does your Makefile look like? > > -- > John > |
From: Dmitry K. <ka...@mc...> - 2013-06-06 16:36:45
|
It appears that --disable-mpi prevents MPI_Init() from being called by libMesh, which causes libMesh::COMM_WORLD to be left uninitialized, as far as I can determine. Since PETSc is being used, PETSC_COMM_WORLD is set to libMesh::COMM_WORLD and PetscInitialize() is called. Since MPI_Init() has not been called, at that stage PETSc expects PETSC_COMM_WORLD to be MPI_COMM_NULL, not the uninitialized libMesh::COMM_WORLD. Hence, the error you see. It seems to me that --disable-mpi in libMesh is a bad option when using PETSc :-) I'm not sure why using MPI cases a conflict with ParMetis for you. That issue seems to be closer to the root cause of you trouble. Dmitry. On Thu, Jun 6, 2013 at 11:09 AM, Andrew Davis <and...@gm...> wrote: > Hi, > > I'm using cmake to generate the Makefile so it is difficult to interpret, > but you are quite right about the PETSc DM issue; I completely forgot to > tell cmake where the PETSc libraries live. I added this to CMakeLists.txt > and re-complied my code and now I get this error (at runtime) when I > initialize libMesh: > > [-1]PETSC ERROR: --------------------- Error Message > ------------------------------------ > [-1]PETSC ERROR: No support for this operation for this object type! > [-1]PETSC ERROR: You cannot set PETSC_COMM_WORLD if you have not > initialized MPI first! > [-1]PETSC ERROR: > ------------------------------------------------------------------------ > [-1]PETSC ERROR: > [-1]PETSC ERROR: See docs/changes/index.html for recent updates. > [-1]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > [-1]PETSC ERROR: See docs/index.html for manual pages. > [-1]PETSC ERROR: > ------------------------------------------------------------------------ > [-1]PETSC ERROR: Libraries linked from > /Users/Andy/software/petsc/arch-darwin-c-debug/lib > [-1]PETSC ERROR: Configure run at Wed Jun 5 17:06:06 2013 > [-1]PETSC ERROR: Configure options --with-cc=gcc --with-fc=gfortran > --download-f-blas-lapack --download-mpich > [-1]PETSC ERROR: > ------------------------------------------------------------------------ > [-1]PETSC ERROR: PetscInitialize() line 676 in > /Users/Andy/software/petsc/src/sys/objects/pinit.c > [-1]PETSC ERROR: LibMeshInit() line 457 in > "unknowndirectory/"src/base/libmesh.C > > Could this be because I had to add the --disable-mpi flag to libMesh when I > configured? If I don't disable MPI when I configure libMesh the compiler > complains (at compile time): > > petsc/arch-darwin-c-debug/include/mpicxx.h:2723:34: error: declaration of C > function 'void Parmetis::MPI::Init(int&, char**&)' conflicts with > extern void Init(int &, char **& ); > > Thanks for your help, > Andy > > > On Thu, Jun 6, 2013 at 11:19 AM, John Peterson <jwp...@gm...> wrote: > >> On Thu, Jun 6, 2013 at 8:44 AM, Andrew Davis <and...@gm...> wrote: >> > Hi, >> > >> > I am trying to solve a nonlinear PDE with libMesh. I have installed >> > libmesh with petsc enabled and I have written a simple "hello world" >> > program that links with the library mesh_dbg, which complies fine. >> > However, at runtime I get the message: >> > >> > dyld: Symbol not found: _DM_CLASSID >> > Referenced from: /usr/local/lib/libmesh_dbg.0.dylib >> > Expected in: flat namespace >> > in /usr/local/lib/libmesh_dbg.0.dylib >> > Trace/BPT trap: 5 >> >> Might be a PETSc DM thing? >> >> What does your Makefile look like? >> >> -- >> John >> > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |
From: Roy S. <roy...@ic...> - 2013-06-06 16:46:52
|
On Thu, 6 Jun 2013, Dmitry Karpeyev wrote: > It seems to me that --disable-mpi in libMesh is a bad option when > using PETSc :-) Actually, our continuous integration tests --disable-mpi using PETSc. *But*, you have to compile and link against a PETSc build which was configured to be "uniprocessor" and avoid MPI as well. If your PETSc is MPI-aware, your libMesh needs to be too. > That issue seems to be closer to the root cause of you trouble. Definitely. --- Roy |
From: Andrew D. <and...@gm...> - 2013-06-06 20:07:31
|
Thanks! This makes sense. I recompiled PETSc with the option --with-mpi=0 and then installed libMesh with --disable-mpi. I'm no longer having trouble initializing libMesh! However, I am still not quite up and running. I create a libMesh::EquationSystems with a libMesh::NonlinearImplicitSystem attached. However, when I run EquationSystems::Init() I get the runtime error [0]PETSC ERROR: PetscCommDuplicate() line 140 in petsc/src/sys/objects/tagm.c [0]PETSC ERROR: PetscHeaderCreate_Private() line 55 in petsc/src/sys/objects/inherit.c [0]PETSC ERROR: VecCreate() line 39 in petsc/src/vec/vec/interface/veccreate.c [0]PETSC ERROR: VecCreateGhostWithArray() line 374 in petsc/src/vec/vec/impls/mpi/pbvec.c [0]PETSC ERROR: VecCreateGhost() line 447 in petsc/src/vec/vec/impls/mpi/pbvec.c [0]PETSC ERROR: init() line 894 in "unknowndirectory/"./include/libmesh/petsc_vector.h Abort trap: 6 Is this related to the MPI issue from I was having earlier? Does libMesh not work with the --disable-mpi option? Am I turning off mpi correctly when I reconfigure PETSc? Thanks again for all your help, Andy On Thu, Jun 6, 2013 at 12:46 PM, Roy Stogner <roy...@ic...>wrote: > > On Thu, 6 Jun 2013, Dmitry Karpeyev wrote: > > It seems to me that --disable-mpi in libMesh is a bad option when >> using PETSc :-) >> > > Actually, our continuous integration tests --disable-mpi using PETSc. > > *But*, you have to compile and link against a PETSc build which was > configured to be "uniprocessor" and avoid MPI as well. > > If your PETSc is MPI-aware, your libMesh needs to be too. > > > That issue seems to be closer to the root cause of you trouble. >> > > Definitely. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2013-06-06 20:19:44
|
On Thu, 6 Jun 2013, Andrew Davis wrote: > I create a libMesh::EquationSystems with a > libMesh::NonlinearImplicitSystem attached. However, when I run > EquationSystems::Init() I get the runtime error Is there an error type? This looks like just a stack trace, but doesn't PETSc also let you know what assertion or signal killed you? > [0]PETSC ERROR: PetscCommDuplicate() line 140 in petsc/src/sys/objects/tagm.c > [0]PETSC ERROR: PetscHeaderCreate_Private() line 55 in petsc/src/sys/objects/inherit.c > [0]PETSC ERROR: VecCreate() line 39 in petsc/src/vec/vec/interface/veccreate.c > [0]PETSC ERROR: VecCreateGhostWithArray() line 374 in petsc/src/vec/vec/impls/mpi/pbvec.c > [0]PETSC ERROR: VecCreateGhost() line 447 in petsc/src/vec/vec/impls/mpi/pbvec.c > [0]PETSC ERROR: init() line 894 in "unknowndirectory/"./include/libmesh/petsc_vector.h > Abort trap: 6 > > Is this related to the MPI issue from I was having earlier? Does > libMesh not work with the --disable-mpi option? Am I turning off > mpi correctly when I reconfigure PETSc? We've got libMesh with --disable-mpi passing continuous integration tests now, and all we do there is --with-mpi=0 for PETSc... This certainly *looks* like some kind of MPI issue, though! --- Roy |
From: Dmitry K. <ka...@mc...> - 2013-06-06 20:47:49
|
Is this the complete error message? Can you run with -on_error_attach_debugger and send the backtrace along with petsc's configure.log? Dmitry. On Thu, Jun 6, 2013 at 3:19 PM, Roy Stogner <roy...@ic...> wrote: > > On Thu, 6 Jun 2013, Andrew Davis wrote: > >> I create a libMesh::EquationSystems with a >> libMesh::NonlinearImplicitSystem attached. However, when I run >> EquationSystems::Init() I get the runtime error > > > Is there an error type? This looks like just a stack trace, but > doesn't PETSc also let you know what assertion or signal killed you? > > >> [0]PETSC ERROR: PetscCommDuplicate() line 140 in >> petsc/src/sys/objects/tagm.c >> [0]PETSC ERROR: PetscHeaderCreate_Private() line 55 in >> petsc/src/sys/objects/inherit.c >> [0]PETSC ERROR: VecCreate() line 39 in >> petsc/src/vec/vec/interface/veccreate.c >> [0]PETSC ERROR: VecCreateGhostWithArray() line 374 in >> petsc/src/vec/vec/impls/mpi/pbvec.c >> [0]PETSC ERROR: VecCreateGhost() line 447 in >> petsc/src/vec/vec/impls/mpi/pbvec.c >> [0]PETSC ERROR: init() line 894 in >> "unknowndirectory/"./include/libmesh/petsc_vector.h >> Abort trap: 6 >> >> Is this related to the MPI issue from I was having earlier? Does >> libMesh not work with the --disable-mpi option? Am I turning off >> mpi correctly when I reconfigure PETSc? > > > We've got libMesh with --disable-mpi passing continuous integration > tests now, and all we do there is --with-mpi=0 for PETSc... This > certainly *looks* like some kind of MPI issue, though! > --- > Roy |
From: Andrew D. <and...@gm...> - 2013-06-06 20:45:49
|
Hi, >Is there an error type? This looks like just a stack trace, but >doesn't PETSc also let you know what assertion or signal killed you? Yes, I agree this is just a stack trace, but it is the only thing that prints when the program crashes. >We've got libMesh with --disable-mpi passing continuous integration >tests now, and all we do there is --with-mpi=0 for PETSc... This >certainly *looks* like some kind of MPI issue, though! This does look like some kind of MPI issue. Just to be safe I tried reinstalling MPI and then reconfigure/compiling PETSc and libMesh. This resulted in the same runtime error (the stack trace) as before. I'm not really sure what else to I could do to figure out what the issue is. Thanks again, Andy On Thu, Jun 6, 2013 at 4:19 PM, Roy Stogner <roy...@ic...>wrote: > > On Thu, 6 Jun 2013, Andrew Davis wrote: > > I create a libMesh::EquationSystems with a >> libMesh::**NonlinearImplicitSystem attached. However, when I run >> EquationSystems::Init() I get the runtime error >> > > Is there an error type? This looks like just a stack trace, but > doesn't PETSc also let you know what assertion or signal killed you? > > > [0]PETSC ERROR: PetscCommDuplicate() line 140 in >> petsc/src/sys/objects/tagm.c >> [0]PETSC ERROR: PetscHeaderCreate_Private() line 55 in >> petsc/src/sys/objects/inherit.**c >> [0]PETSC ERROR: VecCreate() line 39 in petsc/src/vec/vec/interface/** >> veccreate.c >> [0]PETSC ERROR: VecCreateGhostWithArray() line 374 in >> petsc/src/vec/vec/impls/mpi/**pbvec.c >> [0]PETSC ERROR: VecCreateGhost() line 447 in petsc/src/vec/vec/impls/mpi/ >> **pbvec.c >> [0]PETSC ERROR: init() line 894 in "unknowndirectory/"./include/** >> libmesh/petsc_vector.h >> Abort trap: 6 >> >> Is this related to the MPI issue from I was having earlier? Does >> libMesh not work with the --disable-mpi option? Am I turning off >> mpi correctly when I reconfigure PETSc? >> > > We've got libMesh with --disable-mpi passing continuous integration > tests now, and all we do there is --with-mpi=0 for PETSc... This > certainly *looks* like some kind of MPI issue, though! > --- > Roy |
From: Jed B. <je...@59...> - 2013-06-06 20:55:37
|
Andrew Davis <and...@gm...> writes: > This does look like some kind of MPI issue. Just to be safe I tried > reinstalling MPI and then reconfigure/compiling PETSc and libMesh. Exactly which options are you configuring with? This message makes it sound like you have an MPI-enabled PETSc and a libMesh configured without MPI. > This resulted in the same runtime error (the stack trace) as before. Which one? In MPI_Attr_get? Can you attach a debugger and find out what out what the value of comm was? MPIUNI's implementation is simple: int MPI_Attr_get(MPI_Comm comm,int keyval,void *attribute_val,int *flag) { if (comm-1 < 0 || comm-1 > 3) return 1; if (!keyval) Keyval_setup(); *flag = attr[comm-1][keyval].active; *(void**)attribute_val = attr[comm-1][keyval].attribute_val; return MPI_SUCCESS; } It appears that libMesh::COMM_WORLD is being set to 0 when not using MPI? |
From: Andrew D. <and...@gm...> - 2013-06-13 14:48:32
|
Hi, Sorry for the delay getting back do you on this. I think I managed to solve some of my issues but haven't quite figured it out exactly. I think this is at least a different issue than before. Previously, I had installed MPI with Homebrew which was apparently installing it in some way libMesh/PETSc couldn't understand. When I installed it by hand I got both PETSc and libMesh to install without having to disable MPI. I also ran make check on libMesh and all of the tests have passed. However, I still get a runtime error when I initialize libMesh. Here is the code: #include "libmesh/libmesh.h" int main(int argc, char** argv) { libMesh::LibMeshInit init(argc,argv); return 0; } and I get the (runtime) error: [Andrews-MacBook-Pro.local:10106] [[INVALID],INVALID] ORTE_ERROR_LOG: Unknown error: -1 in file runtime/orte_globals.c at line 218 [Andrews-MacBook-Pro:10106] *** Process received signal *** [Andrews-MacBook-Pro:10106] Signal: Segmentation fault: 11 (11) [Andrews-MacBook-Pro:10106] Signal code: Address not mapped (1) [Andrews-MacBook-Pro:10106] Failing at address: 0x0 [Andrews-MacBook-Pro:10106] [ 0] 2 libsystem_c.dylib 0x00007fff972f894a _sigtramp + 26 [Andrews-MacBook-Pro:10106] [ 1] 3 ??? 0x0000000000000001 0x0 + 1 [Andrews-MacBook-Pro:10106] *** End of error message *** Segmentation fault: 11 Do you know what could be causing this? The error message means very little to me. I have attached the configure log for libMesh. Thanks again! Andy On Thu, Jun 6, 2013 at 4:55 PM, Jed Brown <je...@59...> wrote: > Andrew Davis <and...@gm...> writes: > > > This does look like some kind of MPI issue. Just to be safe I tried > > reinstalling MPI and then reconfigure/compiling PETSc and libMesh. > > Exactly which options are you configuring with? This message makes it > sound like you have an MPI-enabled PETSc and a libMesh configured > without MPI. > > > This resulted in the same runtime error (the stack trace) as before. > > Which one? In MPI_Attr_get? Can you attach a debugger and find out > what out what the value of comm was? MPIUNI's implementation is simple: > > int MPI_Attr_get(MPI_Comm comm,int keyval,void *attribute_val,int *flag) > { > if (comm-1 < 0 || comm-1 > 3) return 1; > if (!keyval) Keyval_setup(); > *flag = attr[comm-1][keyval].active; > *(void**)attribute_val = attr[comm-1][keyval].attribute_val; > return MPI_SUCCESS; > } > > It appears that libMesh::COMM_WORLD is being set to 0 when not using > MPI? > |
From: Paul T. B. <ptb...@gm...> - 2013-06-13 18:21:01
|
ORTE is OpenMPI stuff I think. Make sure you're running the same MPI that you used to build libMesh and PETSc. On Thu, Jun 13, 2013 at 3:48 PM, Andrew Davis <and...@gm...> wrote: > Hi, > > Sorry for the delay getting back do you on this. I think I managed to > solve some of my issues but haven't quite figured it out exactly. I think > this is at least a different issue than before. > > Previously, I had installed MPI with Homebrew which was apparently > installing it in some way libMesh/PETSc couldn't understand. When I > installed it by hand I got both PETSc and libMesh to install without having > to disable MPI. I also ran make check on libMesh and all of the tests have > passed. > > However, I still get a runtime error when I initialize libMesh. Here is > the code: > > #include "libmesh/libmesh.h" > > int main(int argc, char** argv) { > libMesh::LibMeshInit init(argc,argv); > return 0; > } > > and I get the (runtime) error: > > [Andrews-MacBook-Pro.local:10106] [[INVALID],INVALID] ORTE_ERROR_LOG: > Unknown error: -1 in file runtime/orte_globals.c at line 218 > [Andrews-MacBook-Pro:10106] *** Process received signal *** > [Andrews-MacBook-Pro:10106] Signal: Segmentation fault: 11 (11) > [Andrews-MacBook-Pro:10106] Signal code: Address not mapped (1) > [Andrews-MacBook-Pro:10106] Failing at address: 0x0 > [Andrews-MacBook-Pro:10106] [ 0] 2 libsystem_c.dylib > 0x00007fff972f894a _sigtramp + 26 > [Andrews-MacBook-Pro:10106] [ 1] 3 ??? > 0x0000000000000001 0x0 + 1 > [Andrews-MacBook-Pro:10106] *** End of error message *** > Segmentation fault: 11 > > Do you know what could be causing this? The error message means very > little to me. I have attached the configure log for libMesh. > > Thanks again! > Andy > > > > > > > On Thu, Jun 6, 2013 at 4:55 PM, Jed Brown <je...@59...> wrote: > > > Andrew Davis <and...@gm...> writes: > > > > > This does look like some kind of MPI issue. Just to be safe I tried > > > reinstalling MPI and then reconfigure/compiling PETSc and libMesh. > > > > Exactly which options are you configuring with? This message makes it > > sound like you have an MPI-enabled PETSc and a libMesh configured > > without MPI. > > > > > This resulted in the same runtime error (the stack trace) as before. > > > > Which one? In MPI_Attr_get? Can you attach a debugger and find out > > what out what the value of comm was? MPIUNI's implementation is simple: > > > > int MPI_Attr_get(MPI_Comm comm,int keyval,void *attribute_val,int *flag) > > { > > if (comm-1 < 0 || comm-1 > 3) return 1; > > if (!keyval) Keyval_setup(); > > *flag = attr[comm-1][keyval].active; > > *(void**)attribute_val = attr[comm-1][keyval].attribute_val; > > return MPI_SUCCESS; > > } > > > > It appears that libMesh::COMM_WORLD is being set to 0 when not using > > MPI? > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > |
From: Andrew D. <and...@gm...> - 2013-06-14 15:14:47
|
Hi, Yes! Sorry that was a silly mistake of mine in the cmake file; I was pointing to the wrong MPI. It looks like everything is working now. Thanks for all your help! Andrew On Thu, Jun 13, 2013 at 2:20 PM, Paul T. Bauman <ptb...@gm...> wrote: > ORTE is OpenMPI stuff I think. Make sure you're running the same MPI that > you used to build libMesh and PETSc. > > > > On Thu, Jun 13, 2013 at 3:48 PM, Andrew Davis <and...@gm...>wrote: > >> Hi, >> >> Sorry for the delay getting back do you on this. I think I managed to >> solve some of my issues but haven't quite figured it out exactly. I think >> this is at least a different issue than before. >> >> Previously, I had installed MPI with Homebrew which was apparently >> installing it in some way libMesh/PETSc couldn't understand. When I >> installed it by hand I got both PETSc and libMesh to install without >> having >> to disable MPI. I also ran make check on libMesh and all of the tests >> have >> passed. >> >> However, I still get a runtime error when I initialize libMesh. Here is >> the code: >> >> #include "libmesh/libmesh.h" >> >> int main(int argc, char** argv) { >> libMesh::LibMeshInit init(argc,argv); >> return 0; >> } >> >> and I get the (runtime) error: >> >> [Andrews-MacBook-Pro.local:10106] [[INVALID],INVALID] ORTE_ERROR_LOG: >> Unknown error: -1 in file runtime/orte_globals.c at line 218 >> [Andrews-MacBook-Pro:10106] *** Process received signal *** >> [Andrews-MacBook-Pro:10106] Signal: Segmentation fault: 11 (11) >> [Andrews-MacBook-Pro:10106] Signal code: Address not mapped (1) >> [Andrews-MacBook-Pro:10106] Failing at address: 0x0 >> [Andrews-MacBook-Pro:10106] [ 0] 2 libsystem_c.dylib >> 0x00007fff972f894a _sigtramp + 26 >> [Andrews-MacBook-Pro:10106] [ 1] 3 ??? >> 0x0000000000000001 0x0 + 1 >> [Andrews-MacBook-Pro:10106] *** End of error message *** >> Segmentation fault: 11 >> >> Do you know what could be causing this? The error message means very >> little to me. I have attached the configure log for libMesh. >> >> Thanks again! >> Andy >> >> >> >> >> >> >> On Thu, Jun 6, 2013 at 4:55 PM, Jed Brown <je...@59...> wrote: >> >> > Andrew Davis <and...@gm...> writes: >> > >> > > This does look like some kind of MPI issue. Just to be safe I tried >> > > reinstalling MPI and then reconfigure/compiling PETSc and libMesh. >> > >> > Exactly which options are you configuring with? This message makes it >> > sound like you have an MPI-enabled PETSc and a libMesh configured >> > without MPI. >> > >> > > This resulted in the same runtime error (the stack trace) as before. >> > >> > Which one? In MPI_Attr_get? Can you attach a debugger and find out >> > what out what the value of comm was? MPIUNI's implementation is simple: >> > >> > int MPI_Attr_get(MPI_Comm comm,int keyval,void *attribute_val,int *flag) >> > { >> > if (comm-1 < 0 || comm-1 > 3) return 1; >> > if (!keyval) Keyval_setup(); >> > *flag = attr[comm-1][keyval].active; >> > *(void**)attribute_val = attr[comm-1][keyval].attribute_val; >> > return MPI_SUCCESS; >> > } >> > >> > It appears that libMesh::COMM_WORLD is being set to 0 when not using >> > MPI? >> > >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> > |