[Libmesh-users] Has anyone tripped this error?

[Cody P. <cod...@gm...>]

After our libMesh update yesterday.  We've managed to start tripping a new
assertion on nearly all of our Linux systems when running any test in debug
mode + parallel (Yes this is happening in both libMesh and MOOSE):

Assertion `elem->neighbor(n) != remote_elem' failed.
elem->neighbor(n) = Assertion `elem->neighbor(n) != remote_elem' failed.
elem->neighbor(n) = 0
remote_elem = 0
[1] ../src/mesh/mesh_tools.C, line 1042, compiled Apr  1 2013 at 11:44:19

This is occurring during the partitioning phase of the mesh generation as
can be seen by the representative mangled stack trace here (sorry):

[eos:07125] [ 7]
../../../moose_test-dbg(_ZN7libMesh9MeshTools33libmesh_assert_valid_remote_elemsERKNS_8MeshBaseE+0x245)
[0x17b2a05]
[eos:07125] [ 8]
../../../moose_test-dbg(_ZN7libMesh11Partitioner9partitionERNS_8MeshBaseEj+0x5f9)
[0x1950e09]
[eos:07125] [ 9]
../../../moose_test-dbg(_ZN7libMesh8MeshBase15prepare_for_useEb+0x64b)
[0x170e1eb]
[eos:07125] [10]
../../../moose_test-dbg(_ZN7libMesh9MeshTools10Generation10build_cubeERNS_16UnstructuredMeshEjjjddddddN12libMeshEnums8ElemTypeEb+0x448)
[0x174af48]

Just one of our Linux boxes is _not_ barfing these errors at the moment so
we are trying to discover if it's something on our end with the way we are
building or if this particular assert is just a little overzealous.  We've
done clean builds of libMesh a few times on our working and not working box
with the same results.  I'm thinking about doing a "git bisect" since this
was working fine before the update, but before I dive in deeper, does
anyone have any ideas?

Thanks,
Cody