[Ns-developers] Idiotic question about the callbacks

Gustavo Carneiro gjcarneiro at gmail.com
Sun Mar 18 08:15:17 PDT 2012


On Sun, Mar 18, 2012 at 15:03, Tommaso Pecorella <tpecorella at mac.com> wrote:

> 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.
>

That Mac OS X valgrind is buggy is consistent with what it says here:

http://www.sealiesoftware.com/valgrind/

Valgrind is a powerful open-source memory debugger. This is a port of
> Valgrind for Mac OS X.
> http://valgrind.org/
> http://www.apple.com/macosx/
> Caveat programmer
> *This port is UNSUPPORTED and INCOMPLETE and BUGGY. It may not find bugs
> in your program, or run your program correctly, or run your program at all.
> *


So, if anyone is trying to use valgrind in Mac OS X, do it at your own
risk, and know that it isn't supported.

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.
>

I am +0.75 for that.

For the other +0.25: I think valgrind works mostly fine in most linux
distros and pure ns-3 code and not include any non-ns3 libraries, so it may
not be much of a problem if we disable the libraries and stick to linux
systems.

One thing is for sure: we should include at least one linux 32-bit and one
linux 64-bit system.

Thanks.


> Cheers,
>
> T.
>
>
> 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
>
> ITALY
>
>
> email: tommaso.pecorella at unifi.it
>
>        tommaso.pecorella at cnit.it
>
>
> phone : +39-055-4796412
> mobile: +39-320-4379803
> fax   : +39-055-494569
>
>
>
>
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert



More information about the Ns-developers mailing list