Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty years of Valgrind

nnethercote.github.io

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Twenty years of Valgrind

#111

Post by alexott »

azurezyq wrote: post #70
dijonman2 wrote: post #47

Earlier quoted context omitted.

I’m surprised to see the attribution to the tools and not your proposed fixes. Sure the discovery was the first step in the order of operations, but can you elaborate on what enabled you to understand the problem statement and subsequent resolution? There has to be a deeper understanding I think

I can share mine. It's an ads retrieval system. Latency is very sensitive and it has to be efficient. To avoid mem allocations, special hashtables with fixed number of buckets (also open addressing) are used in multiple places in query processing. Default is 1000. However, there are cases that number of elements are only a handful. Then in this case, it fails to utilize the cache, hence slower. The solution is to tun…

I also heavily used callgrind/cachegrind to tune critical paths in our high performance web proxy, we’re each micro/milliseconds counts… For example, in media type detection that is called multiple times per request (minimum twice for request/response), etc.

Re: Twenty years of Valgrind

#112

Post by glandium »

1over137 wrote: post #102
glandium wrote: post #65

Earlier quoted context omitted.

valgrind is available on mac. From the homepage: "It runs on the following platforms: (...) X86/Darwin and AMD64/Darwin (Mac OS X 10.12).". There's a notable omission of ARM64/Darwin in there, and I don't think it's an oversight. What Mac is definitely lacking, though, is reverse debugging. Linux has rr, Windows has Time Travel Debugging. macOS still doesn't have an equivalent.

There have been 6 major releases since 10.12 (which was from late 2016). In other words, valgrind has basically stopped supporting macOS.

I don't think it means it doesn't work with newer versions.

Re: Twenty years of Valgrind

#113

Post by ahartmetz »

Valgrind is fantastic.

Memcheck decreases the memory safety problem of C++ by about 80% in my experience - it really is a big deal. The compiler-based tools that require recompiling every library used are a bit impractical for large stacks such as the ones under Qt-based GUI applications. Several libraries, several build systems. But I hear that they are popular for CI systems in large projects such as web browsers, which probably have dedicated CI developers. There are also some IME rare problems that these tools can find that Memcheck can't, which is due to information unavailable in compiled code. Still, Memcheck has the largest coverage by far.

Callgrind and Cachegrind give very precise, repeatable results, complementary to but not replacing perf and AMD / Intel tooling which use hardware performance counters. I tend to use all of them. They all work without recompiling.

Re: Twenty years of Valgrind

#114

Post by 1over137 »

glandium wrote: post #112
1over137 wrote: post #102

Earlier quoted context omitted.

There have been 6 major releases since 10.12 (which was from late 2016). In other words, valgrind has basically stopped supporting macOS.

I don't think it means it doesn't work with newer versions.

I'm afraid you're wrong. It does not work with newer macOS versions, I've tried.

Re: Twenty years of Valgrind

#115

Post by randomswede »

Not sure if it was still doing it in 2001, but in the 1997-1998 time-frame Purify also ran on HP-UX. The company I was working for at the time used it and we ended up finding a two-byte (IIRC) leak in the HP gethostbyname() library call (well, at least I think it was gethostbyname, it's more than two decades ago).

That was one of the more annoying tickets to file. We could of course send them the binary, but it would not run without the Purify license file, and we weren't comfortable to send off the license file as well. But, in the end, they accepted the bug. Not sure if there was every any fix, though.

Re: Twenty years of Valgrind

#116

Post by bluGill »

intelVISA wrote: post #109
bluGill wrote: post #95

Earlier quoted context omitted.

What language that has anything like cachegrind which is the topic of this thread? Cache misuse is one of the largest causes of bad performance these days, and I can't think of any language that has anything built in for that. Sure other languages have some nice tools to do garbage collection (so does C++, but it is optional, and reference counting does have drawbacks), but there are a lot more to tooling than just g…

To be fair as an outsider to both Rust and Js they seem to have pretty robust package management between cargo and npm, although npm is kinda cheating as collating scripts isn't quite as complex building binaries whereas PIP's absolutely unberable with all the virtual env stuff. I've been quite lucky with CMake, after the initial learning period I've found everything "just works" as it is quite well supported by mode…

Cargo and npm are very robust so long as you stick only to their respective ecosystems. However as soon as you need something from a different eco system they each become hard. The initial import into an ecosystem isn't hard, but the reimport after every update upstream is very annoying.

Re: Twenty years of Valgrind

#117

Post by willfiveash »

I see the article mentions Solaris, an OS that I am very familiar with, which had me thinking about the memory corruption detection Solaris offerred. Among the development features Solaris supported were two memory corruption checking libraries (libumem, watchmalloc) that could easily be used without have to recompile binaries to link with them. Libumem had support for detecting memory leaks, buffer overruns, multiple frees, use of uninitialized data, use of freed data, etc... but it could not detect a read past an allocated buffer which is where watchmalloc came in handy. To use either with an executable binary was as easy as:

$ LD_PRELOAD=libumem.so.1

I found a lot of memory corruption bugs using libumem in particular including some in MIT Kerberos that were severe enough to be considered security vulnerabilities. Sadly, Solaris is now in support mode thanks to Ellison and friends at Oracle.

Re: Twenty years of Valgrind

#118

Post by njs12345 »

seoaeu wrote: post #107
njs12345 wrote: post #105

Earlier quoted context omitted.

> Even rust's memory model has places where it can't do what C++ can. (you can't use atomic to write data from two different threads at the same time) Perhaps not in safe Rust, but can you provide an example of something Rust can't do that C++ can? It has the same memory model as C++20: https://doc.rust-lang.org/nomicon/atomics.html

You totally can in safe rust: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU64.h...

The atomics themselves sure, but I guess often they'll be used as a barrier to protect an UnsafeCell or something, like in the implementation of Lazy: https://docs.rs/lazy-init/0.5.0/src/lazy_init/lib.rs.html#85
Post reply on HN