On Tue, 15 Dec 2009, Rahul Sampath wrote:
> In the following example code:
>
> Mesh * mesh = new Mesh(3);
> delete mesh;
>
> The destructor of mesh is called, which through a bunch of nested
> calls to parent destructors ends up calling BoundaryInfo::clear().
> This calls
> _boundary_node_id.clear(). In the above example, _boundary_node_id
> happens to be empty. According to GCC 4.3.2, clearing an empty
> container is not safe:
Could you give us a full stack trace of the segfault? I'm trying to
replicate this bug myself, but the code above is working fine on my
gcc 4.3.1 libMesh build. A coworker has been experimenting with
deleting empty containers with gcc 4.3.2, and (even when defining the
_GLIBCXX_DEBUG flag needed to get down to the multimap.h snippet you
pasted) he hasn't be able to get a segfault out of it.
> void
> 00190 erase(iterator __first, iterator __last)
> 00191 {
> 00192 // _GLIBCXX_RESOLVE_LIB_DEFECTS
> 00193 // 151. can't currently clear() empty container
> 00194 __glibcxx_check_erase_range(__first, __last);
> 00195 while (__first != __last)
> 00196 this->erase(__first++);
> 00197 }
> 00198
> void
> 00207 clear()
> 00208 { this->erase(begin(), end()); }
Looking at that snippet, in fact, I can't see how it would result in a
segfault. If that range check fails, it should trigger a SIGABRT, not
SIGSEGV. And if the range check doesn't fail, begin() and end()
should be equal and so the while loop should be a do-nothing.
Question for Rahul: is it possible that you've got a segfault
elsewhere in your code, or improperly linked code? e.g. mixing
libMesh versions, compilers, or compiler flag settings like
_GLIBCXX_DEBUG between object files can sometimes result in spurious
segfaults at runtime.
And question for libMesh developers: if it turns out that
empty_container.clear() is supported by old gcc versions, do we want
to use a libmesh_clear() workaround anyway, just in case other
compilers exhibit the problem? I'd say that's overkill, but on the
other hand, we've still got our AutoPtr and OStringStream classes
around to handle some non-C++98 compatible compilers; running into a
non-2003-compatible STL wouldn't be any more unlikely.
---
Roy
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
