On Mon, 25 Oct 2010, David Andrs wrote: > I think I found a bug when I was working on the periodic-boundary patch > (submitted earlier today). If I compiled libmesh in debug mode and ran my > application, it locked up. I figured out that point_locator() is called > (mesh_base.C line 287), it allocated a mutex and then it called a > constructor for PointLocatorBase::build() created object. Since > PointLocatorBase inherits from ReferenceCountedObject, the > increment_constructor_count was called (reference_counter.h, line 167) and it > tried to allocated the same mutex there again. Everything works fine > in OPT mode, since the body of increment_constructor_count is empty. > > Could anyone verify this?
I don't have a test case handy for it, but it looks like you've identified the problem correctly. The general problem is just that we overuse that single Threads::spin_mtx way too much... But the specific problem here is that we shouldn't be bothering to wrap a mutex around that test for construction at all; we're still trying to maintain a "no multithreaded code (including PointLocatorBase::build()) called within multithreaded code" standard, so MeshBase::point_locator() is not currently supposed to be called from within multithreaded code unless the PointLocator has already been constructed. Would you try removing that mutex and double-check and make sure it fixes your problem? If so then we'll remove it permanently. --- Roy ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
