Interpret object causing crash in __cxa_finalize (have core)

Jeffrey Walton
Wed Aug 24 20:19:00 GMT 2011

On Wed, Aug 24, 2011 at 4:03 PM, Jan Kratochvil
<> wrote:
> On Wed, 24 Aug 2011 21:54:09 +0200, Jeffrey Walton wrote:
>> Boost has made Valgrind useless (15000 line of output). And I have not
>> been successful in getting suppression rules:
>> and
> You do not need to track memory leaks but you should track memory corruptions.
> You was told the same in the mails.
We are also interested in memory leaks - other libraries affect our integrity.

OT: we're finding these other libraries are somewhat sloppy, and are
affecting our ability to analyze our stuff. They need to fix their
gear, or we need to find suppression rules.

>> To retain info on the objects in question, do I need to compile with
>> g++ -v and save the intermediate (ii?) files?
> I do not see any missing debug info in your backtrace.
> g++ uses -g for debug info, not -v.
Yes, we have -g3 -ggdb. But we seem to be missing diagnostic
information from __do_global_dtors_aux and __cxa_finalize.

> You did not tell which platform do you run on but it seems to me like
> GNU/Linux, debug info is stored there in the binary files or in separate
> .debug info files (one file per one library) in /usr/lib/debug.  The debug
> info stored in object files is specific only to Apple OSes.
My bad. This is a C++ library (non-Apple).

$ uname -a
Linux studio 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC
2011 x86_64 GNU/Linux

> But after all you have all the debug info you can have in that backtrace.
OK, I' seem to have a misconception. Is there no debug information
associated with global constructors and destructors? If not, how does
one determine the problematic object destructor? Lumping everything
into __cxa_finalize is not helpful.


More information about the Gdb mailing list