[Ns-developers] Idiotic question about the callbacks

Tommaso Pecorella tpecorella at mac.com
Sun Mar 18 08:03:52 PDT 2012

I think the best option would be to find a viable, reliable configuration where to test Valgrind, and keep the rest as a reference.

It seems to me that valgrind results are also very dependent on how debug libraries are built, which compiler is being used and so on.

My 2 cents is to use only a couple of "reference" systems where to run Valgrind on. As an example, fedora seems to give the most clean and precise informations. If a memory leak shows there, then it's a bug 99.9% of the time. While a memory leak in MacOS is 99.9% a false positive. I'd like to have the same reliability on my Mac, but I am unable to get a "clean" output, Too many late-memory-releas stuff.

So my proposal is to define one or two reference systems where to run memory leak checks and kinda forget if Valgrind is complaining on other systems, where "kinda" means we have to consider them, but not raise bugs if they do. Unless we find that a particular library is giving *very bad* memory leaks, such as increasing memory during execution.

Mind that most (if not all) of our memory leaks are classified as "possible", and even Valgrind documentation states that they are not an issue to cry for. They are something to look for, but not to cry for.



On 18 Mar 2012, at 12:27, Gustavo Carneiro wrote:

> On Sun, Feb 26, 2012 at 02:27, John Abraham <jabraham3 at mail.gatech.edu> wrote:
> The valgrind errors seem to vary both intra-OS (Ubuntu 10 vs 11) and inter-OS (Ubuntu vs Fedora), which sometimes made me question the use of valgrind. Still it used by a lot of people.
> Throughout last year while being involved with  various ns-3 builds, I have seen that , now, only Fedora systems can completely "PASS" ns-3 passed through valgrind,  in this generation of gcc.
> I also raised the issue with Tom, that we need to ensure that at least Fedora systems can validate ns-3 with valgrind or pretty soon we will have no releases that can pass valgrind.
> As, very often, ns-3 is used for simulations that last for hours even days, valgrind checks for leaks becomes crucial.
> Ubuntu systems report valgrind errors for ns-3 in a variety of places especially in third-party libraries like libpixman or libselinux. The errors range from leaks to unreachable code to still reachable memory or unconditional jumps. And the Mac, I don't even want to go there. OSX-lion is quite a challenge.
> I understand the pain in using valgrind. And I would also admit, I don't have the ability to narrow down the root-cause of the valgrind errors. I've spent hours on it. Very cryptic and one can only guess.
> I think we have to be able to distinguish between valgrind errors in ns-3 code itself and valgrind errors in 3rd party libraries.  The former I think are important to detect and fix, the latter are just noise and out of our control.
> To avoid valgrind errors in 3rd party libraries, we might want to build ns-3 without linking to those libraries.  Gtk+, for instance, is linked to by default unless it is not found.  We may need to add a --disable-gtk option.  Same for the other libraries.
> The remaining valgrind errors probably denote bugs.  Should we not fix these bugs?
> -- 
> Gustavo J. A. M. Carneiro
> INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
> "The universe is always one step beyond logic." -- Frank Herbert


The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait another year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"


Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze

email: tommaso.pecorella at unifi.it
       tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569

More information about the Ns-developers mailing list