On Sat, Sep 4, 2010 at 11:29 AM, Anna-Lena Gerner <[email protected]> wrote: > > Hi everybody, > > 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) > > ex4-dbg(73819) malloc: *** error for object 0x1032e6fa0: pointer being freed > was not allocated > *** set a breakpoint in malloc_error_break to debug > > Program received signal SIGABRT, Aborted. > 0x00007fff853623d6 in __kill () > (gdb) bt > #0 0x00007fff853623d6 in __kill () > #1 0x00007fff85402972 in abort () > #2 0x00007fff8531a615 in free () > #3 0x0000000100026e0a in __gnu_cxx::new_allocator<char>::deallocate > (this=0x7fff5fbfb5b7, __p=0x1032e6fa0 "") at ext/new_allocator.h:95 > #4 0x0000000100020a61 in std::string::_Rep::_M_destroy (this=0x1032e6fa0, > _...@0x7fff5fbfb61f) at basic_string.tcc:449 > #5 0x000000010001b0e0 in std::string::_Rep::_M_dispose (this=0x1032e6fa0, > _...@0x7fff5fbfb61f) at basic_string.h:236 > #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 > #8 0x000000010161b356 in libMesh::PerfLog::get_log (this=0x7fff5fbfd2f0) at > src/utils/perf_log.C:452 > #9 0x000000010161b450 in libMesh::PerfLog::print_log (this=0x7fff5fbfd2f0) > at src/utils/perf_log.C:469 > #10 0x0000000101619481 in ~PerfLog (this=0x7fff5fbfd2f0) at > src/utils/perf_log.C:61 > #11 0x000000010000568b in assemble_poisson (e...@0x7fff5fbff570, > system_na...@0x10350fc18) at ex4.C:290 > #12 0x00000001015bbb46 in libMesh::System::user_assembly (this=0x10350fb60) > at src/systems/system.C:1451 > #13 0x00000001015b30a0 in libMesh::System::assemble (this=0x10350fb60) at > src/systems/system.C:376 > #14 0x000000010151c0a8 in libMesh::ImplicitSystem::assemble > (this=0x10350fb60) at src/systems/implicit_system.C:173 > #15 0x000000010152a394 in libMesh::LinearImplicitSystem::assemble > (this=0x10350fb60) at linear_implicit_system.h:100 > #16 0x0000000101529e55 in libMesh::LinearImplicitSystem::solve > (this=0x10350fb60) at src/systems/linear_implicit_system.C:86 > #17 0x000000010000392f in main (argc=6, argv=0x7fff5fbff880) at ex4.C:246
Whenever I see a segfault coming from a weird place, in this case, from the destructor of std::string, I usually suspect an incomplete recompile of some sort. For example, object files from an older compiler version getting linked with object files from a new one, etc. Can you see if 'make clobber' and remaking in dbg mode doesn't fix the problem? -- John ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
