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

61–70 of 118 posts

Re: Twenty years of Valgrind

#61

Post by pjmlp »

> Speaking of software quality, I think it’s fitting that I now work full time on Rust, a systems programming language that didn’t exist when Valgrind was created, but which basically prevents all the problems that Memcheck detects.

Just like Ada has been doing since 1983.

Re: Twenty years of Valgrind

#64

Post by jackosdev »

anewpersonality wrote: post #59

Is Valgrind any use in Rust?

I work full-time with Rust, use it all the time to see how much memory is being allocated to the heap, make a change and then see if there's a difference, and also for cache misses:

valgrind target/debug/rustbinary

==10173== HEAP SUMMARY:

==10173== in use at exit: 854,740 bytes in 175 blocks

==10173== total heap usage: 2,046 allocs, 1,871 frees, 3,072,309 bytes allocated

==10173==

==10173== LEAK SUMMARY:

==10173== definitely lost: 0 bytes in 0 blocks

==10173== indirectly lost: 0 bytes in 0 blocks

==10173== possibly lost: 1,175 bytes in 21 blocks

==10173== still reachable: 853,565 bytes in 154 blocks

==10173== suppressed: 0 bytes in 0 blocks

==10173== Rerun with --leak-check=full to see details of leaked memory

valgrind --tool=cachegrind target/debug/rustbinary

==146711==

==146711== I refs: 1,054,791,445

==146711== I1 misses: 11,038,023

==146711== LLi misses: 62,896

==146711== I1 miss rate: 1.05%

==146711== LLi miss rate: 0.01%

==146711==

==146711== D refs: 793,113,817 (368,907,959 rd + 424,205,858 wr)

==146711== D1 misses: 757,883 ( 535,230 rd + 222,653 wr)

==146711== LLd misses: 119,285 ( 49,251 rd + 70,034 wr)

==146711== D1 miss rate: 0.1% ( 0.1% + 0.1% )

==146711== LLd miss rate: 0.0% ( 0.0% + 0.0% )

==146711==

==146711== LL refs: 11,795,906 ( 11,573,253 rd + 222,653 wr)

==146711== LL misses: 182,181 ( 112,147 rd + 70,034 wr)

==146711== LL miss rate: 0.0% ( 0.0% + 0.0% )

Re: Twenty years of Valgrind

#65

Post by glandium »

whimsicalism wrote: post #11

It's unfortunate that so many of these great tools (like `perf` and I believe `valgrind`) are basically not available locally on the Mac. And running in a container is not really a solution for most of these.

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.

Re: Twenty years of Valgrind

#66

Post by glandium »

cjbprime wrote: post #2

I wish I hadn't read this article because now I know that I've been mispronouncing Valgrind for nearly 20 years but I'm not going to stop. (Kidding. Thanks for Valgrind! I still use it for assessing memory corruption vulnerabilities along with ASan.)

I've known the right pronunciation for about 10 years. I still say it wrong.

Re: Twenty years of Valgrind

#67

Post by RustyRussell »

I once submitted a bug fix for an obscure issue to valgrind. They asked for a test case, which I managed to provide, but I was a bit nervous as I couldn't immediately see how to fit in their test suite.

The response from Julian Seward was so nice it set a permanently high bar for me when random people I don't know report bugs on my projects!

We still run our entire testsuite under valgrind in CI. Amazing tool!

Re: Twenty years of Valgrind

#68

Post by bayindirh »

I still use Valgrind memcheck for memory leak verification of a large piece of code I have developed, with a long end-to-end test.

Also, it has a nice integration with Eclipse which reflects the Valgrind memcheck output to the source files directly, enabling you to see where problems are rooted.

All in all, Valgrind is a great toolset.

P.S.: I was pronouncing Valgrind correctly! :)

Re: Twenty years of Valgrind

#69

Post by opan »

cjbprime wrote: post #2

I wish I hadn't read this article because now I know that I've been mispronouncing Valgrind for nearly 20 years but I'm not going to stop. (Kidding. Thanks for Valgrind! I still use it for assessing memory corruption vulnerabilities along with ASan.)

How do you pronounce it? I hoped it'd be near the start, but several paragraphs in and I'm still not sure.

edit: val as in value + grinned

Re: Twenty years of Valgrind

#70

Post by azurezyq »

dijonman2 wrote: post #47
compiler-guy wrote: post #22

I sort of owe callgrind a big chunk of my career. I was working at a company full of PhDs and well seasoned veterans, who looked at me as a new kid, kind of underqualified to be working in their tools group. I had been at the firm for a while, and they were nice enough, but didn't really have me down as someone who was going to contribute as anything other than a very junior engineer. We had a severe problem with a p…

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 tune number of buckets from info derived from the pprof callgraph.

There were others too, like redundant serialization, etc. But this one is the most interesting.

Post reply on HN