libMesh: A C++ Finite Element Library

On 3/14/11 12:36 AM, Roy Stogner wrote:
>
> On Sun, 13 Mar 2011, Boyce Griffith wrote:
>
>> These look like namespace issues --- if I change libmesh_cast_ptr to
>> libMesh::cast_ptr, everything works fine.
>
> You mean libMesh::libmesh_cast_ptr, I assume? ---

Yep.

-- Boyce

> Roy

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
>> Libmesh-devel@...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>>

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

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

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

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
>

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
>>
>

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
>>> 
>> 
>

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
>>>>
>>>
>>
>

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
>>>>>
>>>>
>>>
>>

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

On Mon, Mar 14, 2011 at 11:03 AM, Roy Stogner <roystgnr@...> 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

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<roystgnr@...>  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

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

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
>

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

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
>

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
>

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
>

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

On Mon, Mar 14, 2011 at 12:04 PM, Boyce Griffith <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.


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

On 3/14/11 2:11 PM, John Peterson wrote:
> On Mon, Mar 14, 2011 at 12:04 PM, Boyce Griffith<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.
>
>
> 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

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<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.
>>
>>
>> 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