Subject: [dtn-users] Has anyone tried running DTN2 under valgrind lately?

From: Amy Alford <[email-masked]>
Date: Mon, 12 Nov 2012 11:10:25 -0500

I've been trying to do this, but I get a lot of spurious output.  Most of
it falls into the following couple of categories:

1) Threads shutdown uncleanly.  Sometimes one thread is accessing variables
another thread has already freed.
2) Lots of memory is intentionally freed by the OS on exit.  This wouldn't
be such a problem, since valgrind classifies this as "still reachable"
rather than a memory leak.  However, the gcc STL implementation uses an
internal pointer to the block of memory it has allocated (rather than a
pointer to the beginning of the block).  This causes valgrind to classify
this memory as "possibly lost" instead of "still reachable".

I discovered an environment variable "OASYS_CLEANUP_SINGLETONS" that causes
oasys to delete classes that inherit from Singleton on exit.  This helps
with the valgrind output, but actually causes dtnd to segfault since some
Singletons are already manually deleted.

I have a slew of changes that got the valgrind output down from about 2000
lines to 500, but I'm not sure that my changes don't have unintended
effects.

- Amy

---

From: Alex McMahon <[email-masked]>
Date: Mon, 12 Nov 2012 17:55:48 +0000

Hi Amy,

If you export them mercurial changesets for oasys/DTN2 and post to the
list we could test on our flamebox (which runs nightly unit tests for
DTN2 and oasys under valgrind).

All the best,

Alex

On Mon, 2012-11-12 at 11:10 -0500, Amy Alford wrote:
> I've been trying to do this, but I get a lot of spurious output.  Most
> of it falls into the following couple of categories:
> 
> 
> 1) Threads shutdown uncleanly.  Sometimes one thread is accessing
> variables another thread has already freed.
> 2) Lots of memory is intentionally freed by the OS on exit.  This
> wouldn't be such a problem, since valgrind classifies this as "still
> reachable" rather than a memory leak.  However, the gcc STL
> implementation uses an internal pointer to the block of memory it has
> allocated (rather than a pointer to the beginning of the block).  This
> causes valgrind to classify this memory as "possibly lost" instead of
> "still reachable".
> 
> 
> I discovered an environment variable "OASYS_CLEANUP_SINGLETONS" that
> causes oasys to delete classes that inherit from Singleton on exit.
>  This helps with the valgrind output, but actually causes dtnd to
> segfault since some Singletons are already manually deleted.
> 
> 
> I have a slew of changes that got the valgrind output down from about
> 2000 lines to 500, but I'm not sure that my changes don't have
> unintended effects.
> 
> 
> - Amy
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-users