>> On Sep 4, 2010, at 10:29 AM, Anna-Lena Gerner wrote: >> >>> I installed libMesh on my Mac OS X, and in opt mode everything is just >>> fine. There also seem to be no compilation problems in dbg mode. However, >>> in dbg mode I get the following runtime error: (./ex4-dbg -d 1 -n 20) >>> >>> #6 0x000000010001351b in ~basic_string (this=0x7fff5fbfcad0) at >>> basic_string.h:503 >>> #7 0x00000001016199c4 in libMesh::PerfLog::get_info_header >>> (this=0x7fff5fbfd2f0) at src/utils/perf_log.C:171
Actually looking at it: what's getting destroyed is a temporary string created from an OStringStream (which on any modern compiler is just a typedef for the corresponding standard class). I don't think there's any way that that should be able to fail short of weird compilation problems. (speaking of weird compilation problems: would you try in devel mode? that would at least either rule out or confirm some weird interaction with GCC's STL debugging options) More confusion: Is this only occurring in ex4? It's code that ought to be hit in every single libMesh close whenever the performance logging is on. Plus, it's pretty much pure library code, a non-inlined function that takes no arguments - there's no way for it to be compiled one way in ex4 but a different way in ex3. There's a bunch of functions it calls, like the time of day, which change from run to run, but I don't see anything which ought to change consistently from example to example. --- Roy ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
