From: Jeffrey Walton <noloader@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: GDB Users List <gdb@sourceware.org>
Subject: Re: Interpret object causing crash in __cxa_finalize (have core)
Date: Wed, 24 Aug 2011 20:19:00 -0000 [thread overview]
Message-ID: <CAH8yC8mxDGuAUZDa=YUv5NRe0NObeK4_=w=JDL+xo2wEzNzApw@mail.gmail.com> (raw)
In-Reply-To: <20110824200308.GA20742@host1.jankratochvil.net>
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
next prev parent reply other threads:[~2011-08-24 20:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 19:31 Jeffrey Walton
2011-08-24 19:40 ` Jan Kratochvil
2011-08-24 19:54 ` Jeffrey Walton
2011-08-24 20:03 ` Jan Kratochvil
2011-08-24 20:19 ` Jeffrey Walton [this message]
2011-08-24 20:34 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAH8yC8mxDGuAUZDa=YUv5NRe0NObeK4_=w=JDL+xo2wEzNzApw@mail.gmail.com' \
--to=noloader@gmail.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox