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

71–80 of 118 posts

Re: Twenty years of Valgrind

#71

Post by imetatroll »

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

Sounds like the solution probably had something to do with switching to passing by reference + other changes I would assume.

Re: Twenty years of Valgrind

#72

Post by LAC-Tech »

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 love this story. I'm becoming an older dev now and I've often been blindsided by some insight or finding by juniors - it's really great to see & you've always got to make sure they get credit!

Re: Twenty years of Valgrind

#73

Post by wenc »

Olumde wrote: post #31

Happy birthday Valgrind. Next year you'll be able to drink in the US! Being a UK PhD holder, a sentence stood out out to me was a commentary/comparison between UK and US PhDs: "This was a three year UK PhD, rather than a brutal six-or-more year US PhD." My cousin has a US PhD and judging from what he tells me. It is a lot more rigorous than UK PhDs.

The UK PhD is 3 yrs, after a 1 yr Masters and 3 yr bachelors. (7 years)

The US PhD is usually 4-5 years after a 4 year bachelors (8-9 years). It is a little bit longer with more graduate-level coursework.

That said, the US bachelors starts at age 17 while a UK bachelors starts after 2 years of A-levels. So in terms of length it’s a wash.

Re: Twenty years of Valgrind

#74

Post by saagarjha »

glandium wrote: post #65
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.

Valgrind, as I understand it, was essentially maintained by one engineer at Apple who has since left the company, so nobody has really updated it.

Re: Twenty years of Valgrind

#75

Post by oconnor663 »

pjmlp wrote: post #61

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

My understanding is that dynamically freeing memory is an unsafe operation in Ada, do I have that right?

Re: Twenty years of Valgrind

#76

Post by zasdffaa »

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…

That's surprising. If I was writing this I'd have instrumented the code for the buckets to (optionally) log the use, and probably add an alert.

(being an armchair expert is easy though)

Re: Twenty years of Valgrind

#77

Post by yaantc »

appleflaxen wrote: post #13

What other great tools are there in the vein of valgrind and AFL?

Seconding `rr` as suggested by @tux3, it's great for debugging.

Also, the sanitizers for GCC and Clang (https://github.com/google/sanitizers), and the Clang static analyzer (and tidy too) through CodeChecker (https://codechecker.readthedocs.io/).

For the Clang static analyzer, make sure your LLVM toolchain has the Z3 support enabled (OK in Debian stable for example), and enable cross translation units (CTU) analysis too for better results.

Re: Twenty years of Valgrind

#78

Post by lma21 »

When we moved to Linux, Valgrind was THE tool that saved our as*s day after day after day. An issue in production? rollback, valgrind, fix, push, repeat. Thank you for all the hard work, in fact i don't i can thank you enough.

Re: Twenty years of Valgrind

#79

Post by Sesse__ »

glouwbug wrote: post #10
galangalalgol wrote: post #7

Earlier quoted context omitted.

Our pipelines have asan ( and cpp check clang tidy coverity and coverage stuff) but no valgrind, is there something it is good at that we are missing?

Yeah, valgrind can report L1/L2 cache misses and report the percentage of branch mispredictions. It also reports the exact number of instructions processed, and how many of those instructions cache missed. It's great for improving small code that needs to be performant. I'd use asan over valgrind only for memory leaks. It's faster.

If you only want memory leaks, LSan will do that for you.

In general, I tend to use ASan for nearly everything I used Valgrind for back in the day; it's faster and usually more precise (Valgrind cannot reliably detect small overflows between stack variables). Valgrind if I cannot recompile, or if ASan doesn't find th issue. Callgrind and Cachegrind never; perf does a much better job, much faster. DHAT never; Heaptrack gives me what I want.

Valgrind was and is a fantastic tool; it became part of my standard toolkit together with the editor, compiler, debugger and build system. But technology has moved on for me.

Post reply on HN