From: Boyce G. <gri...@ci...> - 2011-03-14 03:12:41
|
Hi, Guys -- I just updated to the latest svn HEAD, and I am now getting compiler errors in my application code like: /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:204: error: ‘libmesh_cast_ptr’ was not declared in this scope /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:290: error: ‘libmesh_cast_ptr’ was not declared in this scope These look like namespace issues --- if I change libmesh_cast_ptr to libMesh::cast_ptr, everything works fine. -- Boyce |
From: Boyce G. <gri...@ci...> - 2011-03-14 03:21:13
|
I'm also now seeing runtime errors that seem to involve variant_filter_iterator: /sw/lib/gcc4.4/lib/gcc/i386-apple-darwin9.8.0/4.4.4/../../../../include/c++/4.4.4/debug/safe_iterator.h:175: error: attempt to dereference a past-the-end iterator. Objects involved in the operation: iterator "this" @ 0x0x49310c4 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPN7libMesh4ElemENSt6__norm6vectorIS5_SaIS5_EEEEENSt7__debug6vectorIS5_S9_EEEE (mutable iterator); state = past-the-end; references sequence with type `NSt7__debug6vectorIPN7libMesh4ElemESaIS3_EEE' @ 0x0x49310c4 } Program received signal SIGABRT, Aborted. 0x9043ce42 in __kill () (gdb) where #0 0x9043ce42 in __kill () #1 0x9043ce34 in kill$UNIX2003 () #2 0x904af23a in raise () #3 0x904bb679 in abort () #4 0x046f782a in __gnu_debug::_Error_formatter::_M_error () #5 0x00e42971 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, std::__norm::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >, std::__debug::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >::operator* (this=0x49310c4) at debug/safe_iterator.h:173 #6 0x00e3e364 in variant_filter_iterator<libMesh::Predicates::multi_predicate, libMesh::Elem*, libMesh::Elem*&, libMesh::Elem**>::Iter<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, std::__norm::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >, std::__debug::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > > >::operator* (this=0x49310c0) at variant_filter_iterator.h:179 #7 0x00e61282 in variant_filter_iterator<libMesh::Predicates::multi_predicate, libMesh::Elem*, libMesh::Elem*&, libMesh::Elem**>::operator* (this=0xbfff792c) at variant_filter_iterator.h:408 #8 0x00e56b7b in libMesh::UnstructuredMesh::find_neighbors (this=0xbfffd79c, reset_remote_elements=false, reset_current_list=true) at src/mesh/unstructured_mesh.C:200 #9 0x00ce79b1 in libMesh::MeshBase::prepare_for_use (this=0xbfffd79c, skip_renumber_nodes_and_elements=false) at src/mesh/mesh_base.C:98 #10 0x00d59b5b in libMesh::MeshTools::Generation::build_cube (mesh=@0xbfffd79c, nx=56, ny=2, nz=0, xmin=0, xmax=1.5707963267948966, ymin=0, ymax=0.0625, zmin=0, zmax=0, type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1438 #11 0x00d59d5e in libMesh::MeshTools::Generation::build_square (mesh=@0xbfffd79c, nx=56, ny=2, xmin=0, xmax=1.5707963267948966, ymin=0, ymax=0.0625, type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1501 #12 0x00004a26 in main (argc=2, argv=0xbfffe004) at ../../../../../IBAMR/examples/IBFE/explicit/ex1/main.C:355 On 3/13/11 10:55 PM, Boyce Griffith wrote: > Hi, Guys -- > > I just updated to the latest svn HEAD, and I am now getting compiler > errors in my application code like: > > /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:204: > error: ‘libmesh_cast_ptr’ was not declared in this scope > > /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:290: > error: ‘libmesh_cast_ptr’ was not declared in this scope > > These look like namespace issues --- if I change libmesh_cast_ptr to > libMesh::cast_ptr, everything works fine. > > -- Boyce |
From: Roy S. <roy...@ic...> - 2011-03-14 04:41:56
|
Assuming this is still broken in r4257 (and I can't see why it shouldn't be, although I also can't see how r4246 would have caused a runtime problem in the first place...): Can you verify that these errors go away if you revert only the variant_filter_iterator.h file to r4245? --- Roy On Sun, 13 Mar 2011, Boyce Griffith wrote: > I'm also now seeing runtime errors that seem to involve > variant_filter_iterator: > > /sw/lib/gcc4.4/lib/gcc/i386-apple-darwin9.8.0/4.4.4/../../../../include/c++/4.4.4/debug/safe_iterator.h:175: > error: attempt to dereference a past-the-end iterator. > > Objects involved in the operation: > iterator "this" @ 0x0x49310c4 { > type = > N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPN7libMesh4ElemENSt6__norm6vectorIS5_SaIS5_EEEEENSt7__debug6vectorIS5_S9_EEEE > (mutable iterator); > state = past-the-end; > references sequence with type > `NSt7__debug6vectorIPN7libMesh4ElemESaIS3_EEE' @ 0x0x49310c4 > } > > Program received signal SIGABRT, Aborted. > 0x9043ce42 in __kill () > (gdb) where > #0 0x9043ce42 in __kill () > #1 0x9043ce34 in kill$UNIX2003 () > #2 0x904af23a in raise () > #3 0x904bb679 in abort () > #4 0x046f782a in __gnu_debug::_Error_formatter::_M_error () > #5 0x00e42971 in > __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, std::__norm::vector<libMesh::Elem*, > std::allocator<libMesh::Elem*> > >, std::__debug::vector<libMesh::Elem*, > std::allocator<libMesh::Elem*> > >::operator* (this=0x49310c4) at > debug/safe_iterator.h:173 > #6 0x00e3e364 in > variant_filter_iterator<libMesh::Predicates::multi_predicate, > libMesh::Elem*, libMesh::Elem*&, > libMesh::Elem**>::Iter<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, > std::__norm::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >, > std::__debug::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > > > >::operator* (this=0x49310c0) at variant_filter_iterator.h:179 > #7 0x00e61282 in > variant_filter_iterator<libMesh::Predicates::multi_predicate, > libMesh::Elem*, libMesh::Elem*&, libMesh::Elem**>::operator* > (this=0xbfff792c) at variant_filter_iterator.h:408 > #8 0x00e56b7b in libMesh::UnstructuredMesh::find_neighbors > (this=0xbfffd79c, reset_remote_elements=false, reset_current_list=true) > at src/mesh/unstructured_mesh.C:200 > #9 0x00ce79b1 in libMesh::MeshBase::prepare_for_use (this=0xbfffd79c, > skip_renumber_nodes_and_elements=false) at src/mesh/mesh_base.C:98 > #10 0x00d59b5b in libMesh::MeshTools::Generation::build_cube > (mesh=@0xbfffd79c, nx=56, ny=2, nz=0, xmin=0, xmax=1.5707963267948966, > ymin=0, ymax=0.0625, zmin=0, zmax=0, type=libMeshEnums::QUAD4, > gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1438 > #11 0x00d59d5e in libMesh::MeshTools::Generation::build_square > (mesh=@0xbfffd79c, nx=56, ny=2, xmin=0, xmax=1.5707963267948966, ymin=0, > ymax=0.0625, type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at > src/mesh/mesh_generation.C:1501 > #12 0x00004a26 in main (argc=2, argv=0xbfffe004) at > ../../../../../IBAMR/examples/IBFE/explicit/ex1/main.C:355 > > On 3/13/11 10:55 PM, Boyce Griffith wrote: >> Hi, Guys -- >> >> I just updated to the latest svn HEAD, and I am now getting compiler >> errors in my application code like: >> >> /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:204: >> error: ‘libmesh_cast_ptr’ was not declared in this scope >> >> /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:290: >> error: ‘libmesh_cast_ptr’ was not declared in this scope >> >> These look like namespace issues --- if I change libmesh_cast_ptr to >> libMesh::cast_ptr, everything works fine. >> >> -- Boyce > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Boyce G. <gri...@ci...> - 2011-03-14 05:01:46
|
Hi, Roy -- The error is apparently still there in r4245. I think that I was using something around r4227 prior to updating, but I didn't think to check, so I'm not certain as to the precise rev number. -- Boyce On 3/14/11 12:41 AM, Roy Stogner wrote: > > Assuming this is still broken in r4257 (and I can't see why it > shouldn't be, although I also can't see how r4246 would have caused a > runtime problem in the first place...): > > Can you verify that these errors go away if you revert only the > variant_filter_iterator.h file to r4245? > --- > Roy > > On Sun, 13 Mar 2011, Boyce Griffith wrote: > >> I'm also now seeing runtime errors that seem to involve >> variant_filter_iterator: >> >> /sw/lib/gcc4.4/lib/gcc/i386-apple-darwin9.8.0/4.4.4/../../../../include/c++/4.4.4/debug/safe_iterator.h:175: >> >> error: attempt to dereference a past-the-end iterator. >> >> Objects involved in the operation: >> iterator "this" @ 0x0x49310c4 { >> type = >> N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPN7libMesh4ElemENSt6__norm6vectorIS5_SaIS5_EEEEENSt7__debug6vectorIS5_S9_EEEE >> >> (mutable iterator); >> state = past-the-end; >> references sequence with type >> `NSt7__debug6vectorIPN7libMesh4ElemESaIS3_EEE' @ 0x0x49310c4 >> } >> >> Program received signal SIGABRT, Aborted. >> 0x9043ce42 in __kill () >> (gdb) where >> #0 0x9043ce42 in __kill () >> #1 0x9043ce34 in kill$UNIX2003 () >> #2 0x904af23a in raise () >> #3 0x904bb679 in abort () >> #4 0x046f782a in __gnu_debug::_Error_formatter::_M_error () >> #5 0x00e42971 in >> __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, >> std::__norm::vector<libMesh::Elem*, >> std::allocator<libMesh::Elem*> > >, std::__debug::vector<libMesh::Elem*, >> std::allocator<libMesh::Elem*> > >::operator* (this=0x49310c4) at >> debug/safe_iterator.h:173 >> #6 0x00e3e364 in >> variant_filter_iterator<libMesh::Predicates::multi_predicate, >> libMesh::Elem*, libMesh::Elem*&, >> libMesh::Elem**>::Iter<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, >> >> std::__norm::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >, >> std::__debug::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > > >> >::operator* (this=0x49310c0) at variant_filter_iterator.h:179 >> #7 0x00e61282 in >> variant_filter_iterator<libMesh::Predicates::multi_predicate, >> libMesh::Elem*, libMesh::Elem*&, libMesh::Elem**>::operator* >> (this=0xbfff792c) at variant_filter_iterator.h:408 >> #8 0x00e56b7b in libMesh::UnstructuredMesh::find_neighbors >> (this=0xbfffd79c, reset_remote_elements=false, reset_current_list=true) >> at src/mesh/unstructured_mesh.C:200 >> #9 0x00ce79b1 in libMesh::MeshBase::prepare_for_use (this=0xbfffd79c, >> skip_renumber_nodes_and_elements=false) at src/mesh/mesh_base.C:98 >> #10 0x00d59b5b in libMesh::MeshTools::Generation::build_cube >> (mesh=@0xbfffd79c, nx=56, ny=2, nz=0, xmin=0, xmax=1.5707963267948966, >> ymin=0, ymax=0.0625, zmin=0, zmax=0, type=libMeshEnums::QUAD4, >> gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1438 >> #11 0x00d59d5e in libMesh::MeshTools::Generation::build_square >> (mesh=@0xbfffd79c, nx=56, ny=2, xmin=0, xmax=1.5707963267948966, ymin=0, >> ymax=0.0625, type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at >> src/mesh/mesh_generation.C:1501 >> #12 0x00004a26 in main (argc=2, argv=0xbfffe004) at >> ../../../../../IBAMR/examples/IBFE/explicit/ex1/main.C:355 >> >> On 3/13/11 10:55 PM, Boyce Griffith wrote: >>> Hi, Guys -- >>> >>> I just updated to the latest svn HEAD, and I am now getting compiler >>> errors in my application code like: >>> >>> /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:204: >>> error: ‘libmesh_cast_ptr’ was not declared in this scope >>> >>> /Users/griffith/sfw/libmesh/include/base/variant_filter_iterator.h:290: >>> error: ‘libmesh_cast_ptr’ was not declared in this scope >>> >>> These look like namespace issues --- if I change libmesh_cast_ptr to >>> libMesh::cast_ptr, everything works fine. >>> >>> -- Boyce >> >> ------------------------------------------------------------------------------ >> >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> |
From: Roy S. <roy...@ic...> - 2011-03-14 05:15:22
|
On Mon, 14 Mar 2011, Boyce Griffith wrote: > The error is apparently still there in r4245. Hmmm... variant_filter_iterator.h didn't change at all between r4168 (Jan 13) and r4246, and none of these changes have been big ones. The stack trace is such that changes to SerialMesh or UnstructuredMesh could have manifested in an error here... but we haven't been *making* many such changes in a while. This looks suspiciously like mismatched object files to me - can you still reproduce it after a "make distclean" and rebuild? Do you get any errors with "make run_examples", or with a short code you could send me? If so then I can pull out the Macbook and try to reproduce it; if not then the only way to pin it down is for you to binary-search back through the svn log. :-P --- Roy |
From: Boyce G. <gri...@ci...> - 2011-03-14 12:14:16
|
On 3/14/11 1:15 AM, Roy Stogner wrote: > > On Mon, 14 Mar 2011, Boyce Griffith wrote: > >> The error is apparently still there in r4245. > > Hmmm... variant_filter_iterator.h didn't change at all between r4168 > (Jan 13) and r4246, and none of these changes have been big ones. > The stack trace is such that changes to SerialMesh or UnstructuredMesh > could have manifested in an error here... but we haven't been *making* > many such changes in a while. > > This looks suspiciously like mismatched object files to me - can you > still reproduce it after a "make distclean" and rebuild? I had already tried that, but just in case, I just did a completely clean checkout and build, and this still runtime error still pops up. (Although the compile time error is gone --- thanks.) > Do you get any errors with "make run_examples", or with a short code > you could send me? If so then I can pull out the Macbook and try to make run_examples seems to work. Ugh. I will see if I can make a toy example to reproduce. > reproduce it; if not then the only way to pin it down is for you to > binary-search back through the svn log. :-P I'll see what I can come up with. -- Boyce |
From: Boyce G. <gri...@ci...> - 2011-03-14 16:20:23
|
On 3/14/11 8:15 AM, Boyce Griffith wrote: > > > On 3/14/11 1:15 AM, Roy Stogner wrote: >> >> reproduce it; if not then the only way to pin it down is for you to >> binary-search back through the svn log. :-P > > I'll see what I can come up with. Here is an example that triggers this error: #include <mesh.h> #include <mesh_generation.h> #include <string_to_enum.h> int main(int argc, char* argv[]) { LibMeshInit init(argc, argv); Mesh mesh(2); std::string elem_type = "QUAD4"; MeshTools::Generation::build_square( mesh, 1, 1, 0.0, 1.0, 0.0, 1.0, Utility::string_to_enum<ElemType>(elem_type)); return 0; } -- Boyce |
From: Roy S. <roy...@ic...> - 2011-03-14 16:23:19
|
Hell, that simple???? I'll check it out ASAP. Thanks, --- Roy On Mon, 14 Mar 2011, Boyce Griffith wrote: > Here is an example that triggers this error: > > #include <mesh.h> > #include <mesh_generation.h> > #include <string_to_enum.h> > int main(int argc, char* argv[]) > { > LibMeshInit init(argc, argv); > Mesh mesh(2); > std::string elem_type = "QUAD4"; > MeshTools::Generation::build_square( > mesh, > 1, 1, > 0.0, 1.0, > 0.0, 1.0, > Utility::string_to_enum<ElemType>(elem_type)); > return 0; > } > > -- Boyce > |
From: Boyce G. <gri...@ci...> - 2011-03-14 16:29:09
|
In the meantime, I will try to find the rev at which this starts happening. On 3/14/11 12:23 PM, Roy Stogner wrote: > > Hell, that simple???? I'll check it out ASAP. > > Thanks, > --- > Roy > > On Mon, 14 Mar 2011, Boyce Griffith wrote: > >> Here is an example that triggers this error: >> >> #include <mesh.h> >> #include <mesh_generation.h> >> #include <string_to_enum.h> >> int main(int argc, char* argv[]) >> { >> LibMeshInit init(argc, argv); >> Mesh mesh(2); >> std::string elem_type = "QUAD4"; >> MeshTools::Generation::build_square( >> mesh, >> 1, 1, >> 0.0, 1.0, >> 0.0, 1.0, >> Utility::string_to_enum<ElemType>(elem_type)); >> return 0; >> } >> >> -- Boyce >> > |
From: Roy S. <roy...@ic...> - 2011-03-14 16:42:09
|
Thanks. This is looking like one hell of a bug - John tells me that for him it works in opt mode but segfaults in dbg mode; on my laptop I don't get any failure either way! Going to try it on a couple different computers. --- Roy On Mon, 14 Mar 2011, Boyce Griffith wrote: > In the meantime, I will try to find the rev at which this starts happening. > > On 3/14/11 12:23 PM, Roy Stogner wrote: >> >> Hell, that simple???? I'll check it out ASAP. >> >> Thanks, >> --- >> Roy >> >> On Mon, 14 Mar 2011, Boyce Griffith wrote: >> >>> Here is an example that triggers this error: >>> >>> #include <mesh.h> >>> #include <mesh_generation.h> >>> #include <string_to_enum.h> >>> int main(int argc, char* argv[]) >>> { >>> LibMeshInit init(argc, argv); >>> Mesh mesh(2); >>> std::string elem_type = "QUAD4"; >>> MeshTools::Generation::build_square( >>> mesh, >>> 1, 1, >>> 0.0, 1.0, >>> 0.0, 1.0, >>> Utility::string_to_enum<ElemType>(elem_type)); >>> return 0; >>> } >>> >>> -- Boyce >>> >> > |
From: Boyce G. <gri...@ci...> - 2011-03-14 16:46:16
|
OK, it looks like this was introduced in r4248. On 3/14/11 12:41 PM, Roy Stogner wrote: > > Thanks. This is looking like one hell of a bug - John tells me that > for him it works in opt mode but segfaults in dbg mode; on my laptop I > don't get any failure either way! Going to try it on a couple > different computers. > --- > Roy > > On Mon, 14 Mar 2011, Boyce Griffith wrote: > >> In the meantime, I will try to find the rev at which this starts >> happening. >> >> On 3/14/11 12:23 PM, Roy Stogner wrote: >>> >>> Hell, that simple???? I'll check it out ASAP. >>> >>> Thanks, >>> --- >>> Roy >>> >>> On Mon, 14 Mar 2011, Boyce Griffith wrote: >>> >>>> Here is an example that triggers this error: >>>> >>>> #include <mesh.h> >>>> #include <mesh_generation.h> >>>> #include <string_to_enum.h> >>>> int main(int argc, char* argv[]) >>>> { >>>> LibMeshInit init(argc, argv); >>>> Mesh mesh(2); >>>> std::string elem_type = "QUAD4"; >>>> MeshTools::Generation::build_square( >>>> mesh, >>>> 1, 1, >>>> 0.0, 1.0, >>>> 0.0, 1.0, >>>> Utility::string_to_enum<ElemType>(elem_type)); >>>> return 0; >>>> } >>>> >>>> -- Boyce >>>> >>> >> > |
From: Boyce G. <gri...@ci...> - 2011-03-14 16:54:14
|
Here is the stack trace, FWIW: (gdb) where #0 0x955c2e42 in __kill () #1 0x955c2e34 in kill$UNIX2003 () #2 0x9563523a in raise () #3 0x95641679 in abort () #4 0x0334982a in __gnu_debug::_Error_formatter::_M_error () #5 0x00773edb in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, std::__norm::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >, std::__debug::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >::operator* (this=0x3521554) at debug/safe_iterator.h:173 #6 0x0076f8ce in variant_filter_iterator<libMesh::Predicates::multi_predicate, libMesh::Elem*, libMesh::Elem*&, libMesh::Elem**>::Iter<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<libMesh::Elem**, std::__norm::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > >, std::__debug::vector<libMesh::Elem*, std::allocator<libMesh::Elem*> > > >::operator* (this=0x3521550) at variant_filter_iterator.h:179 #7 0x00793c22 in variant_filter_iterator<libMesh::Predicates::multi_predicate, libMesh::Elem*, libMesh::Elem*&, libMesh::Elem**>::operator* (this=0xbfff845c) at variant_filter_iterator.h:408 #8 0x00787603 in libMesh::UnstructuredMesh::find_neighbors (this=0xbfffe040, reset_remote_elements=false, reset_current_list=true) at src/mesh/unstructured_mesh.C:200 #9 0x00630e39 in libMesh::MeshBase::prepare_for_use (this=0xbfffe040, skip_renumber_nodes_and_elements=false) at src/mesh/mesh_base.C:98 #10 0x006c74db in libMesh::MeshTools::Generation::build_cube (mesh=@0xbfffe040, nx=2, ny=2, nz=0, xmin=0, xmax=1, ymin=0, ymax=1, zmin=0, zmax=0, type=libMeshEnums::QUAD9, gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1438 #11 0x006c76de in libMesh::MeshTools::Generation::build_square (mesh=@0xbfffe040, nx=2, ny=2, xmin=0, xmax=1, ymin=0, ymax=1, type=libMeshEnums::QUAD9, gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1501 #12 0x00002b66 in main (argc=1, argv=0xbfffe0d8) at main.C:14 On 3/14/11 12:46 PM, Boyce Griffith wrote: > OK, it looks like this was introduced in r4248. > > On 3/14/11 12:41 PM, Roy Stogner wrote: >> >> Thanks. This is looking like one hell of a bug - John tells me that >> for him it works in opt mode but segfaults in dbg mode; on my laptop I >> don't get any failure either way! Going to try it on a couple >> different computers. >> --- >> Roy >> >> On Mon, 14 Mar 2011, Boyce Griffith wrote: >> >>> In the meantime, I will try to find the rev at which this starts >>> happening. >>> >>> On 3/14/11 12:23 PM, Roy Stogner wrote: >>>> >>>> Hell, that simple???? I'll check it out ASAP. >>>> >>>> Thanks, >>>> --- >>>> Roy >>>> >>>> On Mon, 14 Mar 2011, Boyce Griffith wrote: >>>> >>>>> Here is an example that triggers this error: >>>>> >>>>> #include <mesh.h> >>>>> #include <mesh_generation.h> >>>>> #include <string_to_enum.h> >>>>> int main(int argc, char* argv[]) >>>>> { >>>>> LibMeshInit init(argc, argv); >>>>> Mesh mesh(2); >>>>> std::string elem_type = "QUAD4"; >>>>> MeshTools::Generation::build_square( >>>>> mesh, >>>>> 1, 1, >>>>> 0.0, 1.0, >>>>> 0.0, 1.0, >>>>> Utility::string_to_enum<ElemType>(elem_type)); >>>>> return 0; >>>>> } >>>>> >>>>> -- Boyce >>>>> >>>> >>> >> |
From: Roy S. <roy...@ic...> - 2011-03-14 17:03:31
|
On Mon, 14 Mar 2011, Boyce Griffith wrote: > OK, it looks like this was introduced in r4248. Wait: r4248, the revision that moved libmesh_assert_valid_parallel_ids() to MeshBase?? The default implementation of that is "{}"; how on earth should that be giving us a segfault? Wait, weirder than that: The only places ever calling that changed code are in MeshRefinement and InfElemBuilder... and your test example doesn't even indirectly use either! I have no idea what could be going on here. --- Roy |
From: John P. <pet...@cf...> - 2011-03-14 17:08:32
|
On Mon, Mar 14, 2011 at 11:03 AM, Roy Stogner <roy...@ic...> wrote: > > On Mon, 14 Mar 2011, Boyce Griffith wrote: > >> OK, it looks like this was introduced in r4248. > > Wait: r4248, the revision that moved > libmesh_assert_valid_parallel_ids() to MeshBase?? The default > implementation of that is "{}"; how on earth should that be giving us > a segfault? > > Wait, weirder than that: The only places ever calling that changed > code are in MeshRefinement and InfElemBuilder... and your test example > doesn't even indirectly use either! > > I have no idea what could be going on here. Me neither, other than we might have had a bug lurking for years and some slight change somewhere triggered it. Undefined behavior and all that... I can confirm that Boyce's example runs for me in 4247, and segfaults in 4248. My backtrace is a bit different than his, it doesn't get down into the iterators at all: (gdb) bt #0 0x00007fff85bfcfca in __semwait_signal () #1 0x00007fff85bfce59 in nanosleep () #2 0x00007fff85c49df0 in sleep () #3 0x00000001002e8898 in PetscSleep () at mesh.h:72 #4 0x00000001002c4e64 in PetscAttachDebugger () at mesh.h:72 #5 0x00000001002c4ee5 in PetscAttachDebuggerErrorHandler () at mesh.h:72 #6 0x00000001002c580e in PetscError () at mesh.h:72 #7 0x00000001002c8f10 in PetscDefaultSignalHandler () at mesh.h:72 #8 0x00000001002c8fc5 in PetscSignalHandler_Private () at mesh.h:72 #9 <signal handler called> #10 0x0000000100ab2d8c in libMesh::UnstructuredMesh::find_neighbors (this=0x7fff5fbfed10, reset_remote_elements=false, reset_current_list=true) at src/mesh/unstructured_mesh.C:201 #11 0x00000001009906d3 in libMesh::MeshBase::prepare_for_use (this=0x7fff5fbfed10, skip_renumber_nodes_and_elements=false) at src/mesh/mesh_base.C:98 #12 0x00000001009e3186 in libMesh::MeshTools::Generation::build_cube (mesh=@0x7fff5fbfed10, nx=2, ny=2, nz=0, xmin=0, xmax=1, ymin=0, ymax=1, zmin=0, zmax=0, type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1438 #13 0x00000001009e3219 in libMesh::MeshTools::Generation::build_square (mesh=@0x7fff5fbfed10, nx=2, ny=2, xmin=0, xmax=1, ymin=0, ymax=1, type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1501 #14 0x0000000100002f12 in main (argc=2, argv=0x7fff5fbfedb0) at boyce_bug.cc:26 -- John |
From: Boyce G. <gri...@ci...> - 2011-03-14 17:21:55
|
You folks don't have a valgrind build handy by any chance...? -- Boyce On 3/14/11 1:08 PM, John Peterson wrote: > On Mon, Mar 14, 2011 at 11:03 AM, Roy Stogner<roy...@ic...> wrote: >> >> On Mon, 14 Mar 2011, Boyce Griffith wrote: >> >>> OK, it looks like this was introduced in r4248. >> >> Wait: r4248, the revision that moved >> libmesh_assert_valid_parallel_ids() to MeshBase?? The default >> implementation of that is "{}"; how on earth should that be giving us >> a segfault? >> >> Wait, weirder than that: The only places ever calling that changed >> code are in MeshRefinement and InfElemBuilder... and your test example >> doesn't even indirectly use either! >> >> I have no idea what could be going on here. > > Me neither, other than we might have had a bug lurking for years and > some slight change somewhere triggered it. Undefined behavior and all > that... > > I can confirm that Boyce's example runs for me in 4247, and segfaults in 4248. > > My backtrace is a bit different than his, it doesn't get down into the > iterators at all: > > (gdb) bt > #0 0x00007fff85bfcfca in __semwait_signal () > #1 0x00007fff85bfce59 in nanosleep () > #2 0x00007fff85c49df0 in sleep () > #3 0x00000001002e8898 in PetscSleep () at mesh.h:72 > #4 0x00000001002c4e64 in PetscAttachDebugger () at mesh.h:72 > #5 0x00000001002c4ee5 in PetscAttachDebuggerErrorHandler () at mesh.h:72 > #6 0x00000001002c580e in PetscError () at mesh.h:72 > #7 0x00000001002c8f10 in PetscDefaultSignalHandler () at mesh.h:72 > #8 0x00000001002c8fc5 in PetscSignalHandler_Private () at mesh.h:72 > #9<signal handler called> > #10 0x0000000100ab2d8c in libMesh::UnstructuredMesh::find_neighbors > (this=0x7fff5fbfed10, reset_remote_elements=false, > reset_current_list=true) at src/mesh/unstructured_mesh.C:201 > #11 0x00000001009906d3 in libMesh::MeshBase::prepare_for_use > (this=0x7fff5fbfed10, skip_renumber_nodes_and_elements=false) at > src/mesh/mesh_base.C:98 > #12 0x00000001009e3186 in libMesh::MeshTools::Generation::build_cube > (mesh=@0x7fff5fbfed10, nx=2, ny=2, nz=0, xmin=0, xmax=1, ymin=0, > ymax=1, zmin=0, zmax=0, type=libMeshEnums::QUAD4, > gauss_lobatto_grid=false) at src/mesh/mesh_generation.C:1438 > #13 0x00000001009e3219 in libMesh::MeshTools::Generation::build_square > (mesh=@0x7fff5fbfed10, nx=2, ny=2, xmin=0, xmax=1, ymin=0, ymax=1, > type=libMeshEnums::QUAD4, gauss_lobatto_grid=false) at > src/mesh/mesh_generation.C:1501 > #14 0x0000000100002f12 in main (argc=2, argv=0x7fff5fbfedb0) at boyce_bug.cc:26 |
From: John P. <pet...@cf...> - 2011-03-14 17:46:35
|
Boyce, I've attached the diffs between 4247 and 4248 below. In the sources, could you try commenting out all the new calls to libmesh_assert_valid_parallel_ids(); This should still crash, at least it does for me. If it does for you, that means that adding an empty function body to mesh_base.h in DEBUG mode is causing the code to crash and that really shouldn't happen... Also, you are using GCC 4.4.4, is that correct? -- John svn diff -r4247:4248 Index: include/mesh/parallel_mesh.h =================================================================== --- include/mesh/parallel_mesh.h (revision 4247) +++ include/mesh/parallel_mesh.h (revision 4248) @@ -122,7 +122,7 @@ * elements containers. * Calls libmesh_assert() on each possible failure. */ - void libmesh_assert_valid_parallel_flags() const; + virtual void libmesh_assert_valid_parallel_flags() const; #endif /** Index: include/mesh/mesh_base.h =================================================================== --- include/mesh/mesh_base.h (revision 4247) +++ include/mesh/mesh_base.h (revision 4248) @@ -543,8 +543,17 @@ */ void clear_point_locator (); +#ifdef DEBUG + /** + * Verify id and processor_id consistency of our elements and + * nodes containers. + * Calls libmesh_assert() on each possible failure. + * Currently only implemented on ParallelMesh; a serial data + * structure is much harder to get out of sync. + */ + virtual void libmesh_assert_valid_parallel_ids() const {} +#endif - public: Index: src/mesh/mesh_refinement.C =================================================================== --- src/mesh/mesh_refinement.C (revision 4247) +++ src/mesh/mesh_refinement.C (revision 4248) @@ -519,9 +519,7 @@ if (coarsening_changed_mesh || refining_changed_mesh) { #ifdef DEBUG - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&_mesh); - if (pmesh) - pmesh->libmesh_assert_valid_parallel_ids(); + _mesh.libmesh_assert_valid_parallel_ids(); #endif _mesh.prepare_for_use (/*skip_renumber =*/false); @@ -1602,9 +1600,7 @@ MeshCommunication().make_nodes_parallel_consistent (_mesh, _new_nodes_map); #ifdef DEBUG - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&_mesh); - if (pmesh) - pmesh->libmesh_assert_valid_parallel_ids(); + _mesh.libmesh_assert_valid_parallel_ids(); #endif } Index: src/mesh/inf_elem_builder.C =================================================================== --- src/mesh/inf_elem_builder.C (revision 4247) +++ src/mesh/inf_elem_builder.C (revision 4248) @@ -638,9 +638,7 @@ #ifdef DEBUG - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&this->_mesh); - if (pmesh) - pmesh->libmesh_assert_valid_parallel_ids(); + _mesh.libmesh_assert_valid_parallel_ids(); if (be_verbose) libMesh::out << " added " #ifdef DEBUG /** * Verify id and processor_id consistency of our elements and * nodes containers. * Calls libmesh_assert() on each possible failure. * Currently only implemented on ParallelMesh; a serial data * structure is much harder to get out of sync. */ virtual void libmesh_assert_valid_parallel_ids() const {} #endif |
From: Boyce G. <gri...@ci...> - 2011-03-14 17:55:59
|
To keep thing simple, I updated to 4247 and then updated only mesh_base.h to 4248: ====================================================================== boyce-griffiths-mac-pro:libmesh-petsc-3.1 griffith$ svn diff -r4247 Index: include/mesh/mesh_base.h =================================================================== --- include/mesh/mesh_base.h (revision 4247) +++ include/mesh/mesh_base.h (working copy) @@ -543,8 +543,17 @@ */ void clear_point_locator (); +#ifdef DEBUG + /** + * Verify id and processor_id consistency of our elements and + * nodes containers. + * Calls libmesh_assert() on each possible failure. + * Currently only implemented on ParallelMesh; a serial data + * structure is much harder to get out of sync. + */ + virtual void libmesh_assert_valid_parallel_ids() const {} +#endif - public: ====================================================================== The code still dies a horrible death. On 3/14/11 1:46 PM, John Peterson wrote: > Boyce, > > I've attached the diffs between 4247 and 4248 below. > > In the sources, could you try commenting out all the new calls to > libmesh_assert_valid_parallel_ids(); > > This should still crash, at least it does for me. If it does for you, > that means that adding an empty function body to mesh_base.h in DEBUG > mode is causing the code to crash and that really shouldn't happen... > > Also, you are using GCC 4.4.4, is that correct? > > -- > John > > > > svn diff -r4247:4248 > Index: include/mesh/parallel_mesh.h > =================================================================== > --- include/mesh/parallel_mesh.h (revision 4247) > +++ include/mesh/parallel_mesh.h (revision 4248) > @@ -122,7 +122,7 @@ > * elements containers. > * Calls libmesh_assert() on each possible failure. > */ > - void libmesh_assert_valid_parallel_flags() const; > + virtual void libmesh_assert_valid_parallel_flags() const; > #endif > > /** > Index: include/mesh/mesh_base.h > =================================================================== > --- include/mesh/mesh_base.h (revision 4247) > +++ include/mesh/mesh_base.h (revision 4248) > @@ -543,8 +543,17 @@ > */ > void clear_point_locator (); > > +#ifdef DEBUG > + /** > + * Verify id and processor_id consistency of our elements and > + * nodes containers. > + * Calls libmesh_assert() on each possible failure. > + * Currently only implemented on ParallelMesh; a serial data > + * structure is much harder to get out of sync. > + */ > + virtual void libmesh_assert_valid_parallel_ids() const {} > +#endif > - > public: > > > Index: src/mesh/mesh_refinement.C > =================================================================== > --- src/mesh/mesh_refinement.C (revision 4247) > +++ src/mesh/mesh_refinement.C (revision 4248) > @@ -519,9 +519,7 @@ > if (coarsening_changed_mesh || refining_changed_mesh) > { > #ifdef DEBUG > - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&_mesh); > - if (pmesh) > - pmesh->libmesh_assert_valid_parallel_ids(); > + _mesh.libmesh_assert_valid_parallel_ids(); > #endif > > _mesh.prepare_for_use (/*skip_renumber =*/false); > @@ -1602,9 +1600,7 @@ > MeshCommunication().make_nodes_parallel_consistent > (_mesh, _new_nodes_map); > #ifdef DEBUG > - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&_mesh); > - if (pmesh) > - pmesh->libmesh_assert_valid_parallel_ids(); > + _mesh.libmesh_assert_valid_parallel_ids(); > #endif > } > > Index: src/mesh/inf_elem_builder.C > =================================================================== > --- src/mesh/inf_elem_builder.C (revision 4247) > +++ src/mesh/inf_elem_builder.C (revision 4248) > @@ -638,9 +638,7 @@ > > > #ifdef DEBUG > - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&this->_mesh); > - if (pmesh) > - pmesh->libmesh_assert_valid_parallel_ids(); > + _mesh.libmesh_assert_valid_parallel_ids(); > > if (be_verbose) > libMesh::out<< " added" > > > > > #ifdef DEBUG > /** > * Verify id and processor_id consistency of our elements and > * nodes containers. > * Calls libmesh_assert() on each possible failure. > * Currently only implemented on ParallelMesh; a serial data > * structure is much harder to get out of sync. > */ > virtual void libmesh_assert_valid_parallel_ids() const {} > #endif > |
From: Boyce G. <gri...@ci...> - 2011-03-14 17:50:13
|
Yes, GCC 4.4.4 from Fink, running on OS X 10.5.8. On 3/14/11 1:46 PM, John Peterson wrote: > Boyce, > > I've attached the diffs between 4247 and 4248 below. > > In the sources, could you try commenting out all the new calls to > libmesh_assert_valid_parallel_ids(); > > This should still crash, at least it does for me. If it does for you, > that means that adding an empty function body to mesh_base.h in DEBUG > mode is causing the code to crash and that really shouldn't happen... > > Also, you are using GCC 4.4.4, is that correct? > > -- > John > > > > svn diff -r4247:4248 > Index: include/mesh/parallel_mesh.h > =================================================================== > --- include/mesh/parallel_mesh.h (revision 4247) > +++ include/mesh/parallel_mesh.h (revision 4248) > @@ -122,7 +122,7 @@ > * elements containers. > * Calls libmesh_assert() on each possible failure. > */ > - void libmesh_assert_valid_parallel_flags() const; > + virtual void libmesh_assert_valid_parallel_flags() const; > #endif > > /** > Index: include/mesh/mesh_base.h > =================================================================== > --- include/mesh/mesh_base.h (revision 4247) > +++ include/mesh/mesh_base.h (revision 4248) > @@ -543,8 +543,17 @@ > */ > void clear_point_locator (); > > +#ifdef DEBUG > + /** > + * Verify id and processor_id consistency of our elements and > + * nodes containers. > + * Calls libmesh_assert() on each possible failure. > + * Currently only implemented on ParallelMesh; a serial data > + * structure is much harder to get out of sync. > + */ > + virtual void libmesh_assert_valid_parallel_ids() const {} > +#endif > - > public: > > > Index: src/mesh/mesh_refinement.C > =================================================================== > --- src/mesh/mesh_refinement.C (revision 4247) > +++ src/mesh/mesh_refinement.C (revision 4248) > @@ -519,9 +519,7 @@ > if (coarsening_changed_mesh || refining_changed_mesh) > { > #ifdef DEBUG > - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&_mesh); > - if (pmesh) > - pmesh->libmesh_assert_valid_parallel_ids(); > + _mesh.libmesh_assert_valid_parallel_ids(); > #endif > > _mesh.prepare_for_use (/*skip_renumber =*/false); > @@ -1602,9 +1600,7 @@ > MeshCommunication().make_nodes_parallel_consistent > (_mesh, _new_nodes_map); > #ifdef DEBUG > - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&_mesh); > - if (pmesh) > - pmesh->libmesh_assert_valid_parallel_ids(); > + _mesh.libmesh_assert_valid_parallel_ids(); > #endif > } > > Index: src/mesh/inf_elem_builder.C > =================================================================== > --- src/mesh/inf_elem_builder.C (revision 4247) > +++ src/mesh/inf_elem_builder.C (revision 4248) > @@ -638,9 +638,7 @@ > > > #ifdef DEBUG > - ParallelMesh *pmesh = dynamic_cast<ParallelMesh *>(&this->_mesh); > - if (pmesh) > - pmesh->libmesh_assert_valid_parallel_ids(); > + _mesh.libmesh_assert_valid_parallel_ids(); > > if (be_verbose) > libMesh::out<< " added" > > > > > #ifdef DEBUG > /** > * Verify id and processor_id consistency of our elements and > * nodes containers. > * Calls libmesh_assert() on each possible failure. > * Currently only implemented on ParallelMesh; a serial data > * structure is much harder to get out of sync. > */ > virtual void libmesh_assert_valid_parallel_ids() const {} > #endif > |
From: Roy S. <roy...@ic...> - 2011-03-14 17:55:31
|
That mesh_base.h change should indeed break in crazy crazy ways if it's used to build both object files with -DDEBUG and object files without -DDEBUG and those object files are then mixed together; the presence/lack of a virtual function would probably result in differing vtables. Although I don't understand how the two of you could be accidentally mixing different levels of debugging flags, it's actually something I'd like to support doing on purpose (since it's often useful to just slow down the one particular source file where you want to investigate problems. I'll move the function (but not the calls to it) out of the ifdef wrappers; from what John's been telling me that should fix this bug even if I'm misunderstanding its cause. --- Roy |
From: Boyce G. <gri...@ci...> - 2011-03-14 18:01:26
|
Crap, that is totally what is happening. I am not using the libMesh build system; I am using my own, and I did not realize that I needed to be including -DDEBUG. -- Boyce On 3/14/11 1:55 PM, Roy Stogner wrote: > That mesh_base.h change should indeed break in crazy crazy ways if > it's used to build both object files with -DDEBUG and object files > without -DDEBUG and those object files are then mixed together; the > presence/lack of a virtual function would probably result in differing > vtables. > > Although I don't understand how the two of you could be accidentally > mixing different levels of debugging flags, it's actually something > I'd like to support doing on purpose (since it's often useful to just > slow down the one particular source file where you want to investigate > problems. I'll move the function (but not the calls to it) out of the > ifdef wrappers; from what John's been telling me that should fix this > bug even if I'm misunderstanding its cause. > --- > Roy > |
From: Boyce G. <gri...@ci...> - 2011-03-14 18:04:13
|
Crap, that is totally what is happening. I use my own build system, and I did not realize that I needed to set -DDEBUG manually. Adding that flag fixes everything. -- Boyce On 3/14/11 1:55 PM, Roy Stogner wrote: > That mesh_base.h change should indeed break in crazy crazy ways if > it's used to build both object files with -DDEBUG and object files > without -DDEBUG and those object files are then mixed together; the > presence/lack of a virtual function would probably result in differing > vtables. > > Although I don't understand how the two of you could be accidentally > mixing different levels of debugging flags, it's actually something > I'd like to support doing on purpose (since it's often useful to just > slow down the one particular source file where you want to investigate > problems. I'll move the function (but not the calls to it) out of the > ifdef wrappers; from what John's been telling me that should fix this > bug even if I'm misunderstanding its cause. > --- > Roy > |
From: Roy S. <roy...@ic...> - 2011-03-14 18:11:15
|
On Mon, 14 Mar 2011, Boyce Griffith wrote: > Crap, that is totally what is happening. I use my own build system, and I > did not realize that I needed to set -DDEBUG manually. Adding that flag > fixes everything. Whew - glad we understand the problem, at least. And don't feel bad - I'm using a copy of our examples Makefiles, which are themselves broken because they ignore CPPFLAGS! I'll fix that too... right after I figure out why it wasn't affecting me. Could just be compiler version quirks; just because the vtable is broken in a certain way doesn't guarantee that any particular binary will have a bug triggered by the breakage. --- Roy |
From: John P. <pet...@cf...> - 2011-03-14 18:12:07
|
On Mon, Mar 14, 2011 at 12:04 PM, Boyce Griffith <gri...@ci...> wrote: > Crap, that is totally what is happening. I use my own build system, and I > did not realize that I needed to set -DDEBUG manually. Adding that flag > fixes everything. And I *thought* I was using the libmesh build system, but -DDEBUG/-DNDEBUG was recently separated out from libmesh_CXXFLAGS into libmesh_CPPFLAGS and so I wasn't getting it either... -- John |
From: Boyce G. <gri...@ci...> - 2011-03-14 18:50:56
|
On 3/14/11 2:11 PM, John Peterson wrote: > On Mon, Mar 14, 2011 at 12:04 PM, Boyce Griffith<gri...@ci...> wrote: >> Crap, that is totally what is happening. I use my own build system, and I >> did not realize that I needed to set -DDEBUG manually. Adding that flag >> fixes everything. > > > And I *thought* I was using the libmesh build system, but > -DDEBUG/-DNDEBUG was recently separated out from libmesh_CXXFLAGS into > libmesh_CPPFLAGS and so I wasn't getting it either... > Quick question --- I just noticed that compiling with -DDEBUG seems to yield executables that print out a lot of warnings from OpenMPI (both in my application codes and in the libMesh examples): [boyce-griffiths-mac-pro.local:30268] mca: base: component_find: "mca_paffinity_darwin.so" does not appear to be a valid paffinity MCA dynamic component (ignored) [boyce-griffiths-mac-pro.local:30268] mca: base: component_find: "mca_paffinity_test.so" does not appear to be a valid paffinity MCA dynamic component (ignored) ... Have you all seen this kind of stuff before, and if so, do you have any ideas on how to fix it/get rid of it? Thanks, -- Boyce |
From: Boyce G. <gri...@ci...> - 2011-03-14 18:59:45
|
On 3/14/11 2:51 PM, Boyce Griffith wrote: > > > On 3/14/11 2:11 PM, John Peterson wrote: >> On Mon, Mar 14, 2011 at 12:04 PM, Boyce >> Griffith<gri...@ci...> wrote: >>> Crap, that is totally what is happening. I use my own build system, >>> and I >>> did not realize that I needed to set -DDEBUG manually. Adding that flag >>> fixes everything. >> >> >> And I *thought* I was using the libmesh build system, but >> -DDEBUG/-DNDEBUG was recently separated out from libmesh_CXXFLAGS into >> libmesh_CPPFLAGS and so I wasn't getting it either... >> > > Quick question --- I just noticed that compiling with -DDEBUG seems to > yield executables that print out a lot of warnings from OpenMPI (both in > my application codes and in the libMesh examples): > > [boyce-griffiths-mac-pro.local:30268] mca: base: component_find: > "mca_paffinity_darwin.so" does not appear to be a valid paffinity MCA > dynamic component (ignored) > [boyce-griffiths-mac-pro.local:30268] mca: base: component_find: > "mca_paffinity_test.so" does not appear to be a valid paffinity MCA > dynamic component (ignored) > > ... > > Have you all seen this kind of stuff before, and if so, do you have any > ideas on how to fix it/get rid of it? I'm a moron. I think I screwed up my dynamic libraries while trying to debug this example. -- Boyce |