This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Interpret object causing crash in __cxa_finalize (have core)
On Wed, Aug 24, 2011 at 4:03 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> 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:
>> http://lists.boost.org/boost-users/2011/08/70235.php and
>> http://sourceforge.net/mailarchive/forum.php?thread_name=CAH8yC8k0QAqj%2B4eyQ%3D20aH11Tnb7m43%3DxjCdkxKZY8ssgf3rfg%40mail.gmail.com&forum_name=valgrind-users.
>
> 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.
Jeff