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

91–100 of 118 posts

Re: Twenty years of Valgrind

#91

Post by sumtechguy »

cpeterso wrote: post #55
mynegation wrote: post #18

I am old enough that I started with Purify and I used Valgrind starting from the version 1.0, because Purify was commercial and Solaris only. It saved my behind multiple multiple times.

And BoundsChecker was also great! https://en.m.wikipedia.org/wiki/BoundsChecker

That tool saved me tons of time tracking down bugs. It also taught me to be a better C/C++ programmer. Run time sanitizers like Purify/Valgrind/Boundchecker do not tolerate poor C code. What is kind of cool is you can find whole classes of bugs in your code. Because as devs we get something working once we tend to copy and paste that pattern everywhere. So find a bug in one place you will probably find it a few dozen other places in your codebase.

Re: Twenty years of Valgrind

#92

Post by piker »

wenc wrote: post #73
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.

US college starts around age 18, which I understand is about the time A-levels are completed, so I believe there are 2 more years of education associated with a US PhD.

Re: Twenty years of Valgrind

#93

Post by nullify88 »

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 have a similar experience with xdebug for a PHP shop I used to work at. It feels very similar to being a nerd back at school, rescuing peoples home work, and being rewarded with some respect.

Re: Twenty years of Valgrind

#94

Post by cbrogrammer »

imetatroll wrote: post #71
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

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

That is what many people fail to understand as to why us C programmers dislike C++

Re: Twenty years of Valgrind

#95

Post by bluGill »

nicoburns wrote: post #89
intelVISA wrote: post #87

Earlier quoted context omitted.

Always find it weird when people berate C++ tooling, Valgrind and adjacent friends are legitimately best in class and incredibly useful. Between RAII and a stack of robust static analyzers you'd have to deliberately write unsafe code these days.

That sounds great until you realise in other languages you get that by default without any tooling. And with better guarantees too (C++ static analysers aren’t foolproof). Where C++ tooling really lacks is around library management and build tooling. The problem is less that any of the individual tools don’t work and more that there are many of them and they don’t interoperate nicely.

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 garbage collection. 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)

No language has good tools around library and builds. So long as you stick to exactly one language with the build system of that language things seem nice. However in the real world we have a lot of languages, and a lot of libraries that already exist. Let me know what I can use any build/library tool with this library that builds with autotools, this other one from cmake, here is one with qmake (though at least qt is switching to cmake which is becoming the de-facto c++ standard), just to name a couple that handle dependencies in very different ways.

Re: Twenty years of Valgrind

#96

Post by pjmlp »

cbrogrammer wrote: post #94
imetatroll wrote: post #71

Earlier quoted context omitted.

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

That is what many people fail to understand as to why us C programmers dislike C++

Indeed, because languages with reference parameters preceed C for about 15 years, and are present in most ALGOL derived dialects.

Re: Twenty years of Valgrind

#97

Post by jerf »

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've mentioned this before on HN as a way for a "newbie" to look like a superhero in a job very quickly; nice to hear a story of it actually working!

There is so much code in the world that nobody has even so much as glanced at a profile of, and any non-trivial, unprofiled code base is virtually guaranteed to have some kind of massive performance problem that is also almost trivial to fix like this.

Put this one in your toolbelt, folks. It's also so fast that you can easily try it without having to "schedule" it, and if I'm wrong and there aren't any easy profiling wins, hey, nobody has to know you even looked. Although in that case, you just learned something about the quality of the code base; if there aren't any profiling quick wins, that means someone else claimed them. As the codebase grows the probability of a quick win being available quickly goes to 1.

Re: Twenty years of Valgrind

#98

Post by touisteur »

pjmlp wrote: post #81
oconnor663 wrote: post #75

Earlier quoted context omitted.

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

Depends on which dynamic memory you are talking about. Ada can manage dynamic stacks, strings and arrays on its own. For example, Ada has what one could call type safe VLAs, instead of corrupting the stack like C, you get an exception and can redo the call with a smaller size, for example. As for explicit heap types and Ada.Unchecked_Deallocation , yes if we are speaking about Ada 83. Ada 95 introduced controlled typ…

That said, I still use valgrind because we have to integrate C libraries sometimes (libpcl is my favorite culprit, only because I'm trying , and there's still possibility to blow the stack (yeah you can use gnatstack to get a good idea of your maximum stack size, but it's doesn't cover the whole Ada featureset and stack canaries - fstack-check don't catch everything.

edit Also massif, call/cachegrind and hellgrind have saved our bacon many, many times.

Even more interesting is writing your own tools with valgrind. Here https://github.com/AdaCore/gnatcoverage/tree/master/tools/gn... is the code of a branch-trace adapter for valgrind (outputs all branches taken/not-taken in 'qemu' format). Very useful if you can run a pintool or Intel Processor Trace just for that.

And if you keep digging, the angr symbolic execution toolkit use (used?) VEX as an intermediate representation. end of edit

Ada doesn't catch uninitialized variables by default (although warnings are getting better). You can either go Spark 'bronze level' (dataflow proof, every variable is initialized) or use 'pragma Initialize_Scalars' combined with -gnatVa.

Some of these techniques described in that now old blog post full of links https://blog.adacore.com/running-american-fuzzy-lop-on-your-... (shameless plug) where one can infer that even proof of absence of runtime errors isn't a panacea and fuzzing still has its use even on fully-proved SPARK code.

Re: Twenty years of Valgrind

#99

Post by sealeck »

RustyRussell wrote: post #67

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!

What was the response?

Re: Twenty years of Valgrind

#100

Post by dahart »

koolba wrote: post #28
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.)

What other ways are there to (mis)pronounce it?

There are so many amazing ways! ;)

Since it’s an old Norse word, try using Google Translate to hear what happens in Danish, Dutch, German, Icelandic, Norwegian, and Swedish. I don’t know if it’s a modern word in those languages, but Translate is showing translations “election gate” for several languages, and “fall gravel” for Swedish.

According to the audio pronunciations on Translate…

Danish: “vale grint”, long a, hard tapped r, hard d sounds like t

Dutch: sounds like “fall hint” but there’s a slight throaty r in there hard to hear for English speakers, so maybe “hrint”

German: “val grinned”, val like value, grinned with the normal German r

Icelandic: “vall grint”, vall like fall, hard tapped r

Norwegian: “vall grin”, hard tapped r, almost “vall g’din”, silent or nearly silent d/t at the end.

Swedish: “voll grint / g’dint”, hard tapped r, hard d

German is the only one that has “Val” like “value”, all the rest sound more like “fall”. The word valgrind is the door to Valhalla, which means literally “fall hall”, as in hall of the fallen. For that reason, I suspect it makes the most sense to pronounce valgrind like “fall grinned”, but Old Norse might have used val like value, I’m not sure.

BTW Valhalla has an equally amusing number of ways to pronounce it across Germanic languages, “val” sometimes turns into what sound like “fell” instead of “fall”, and in Icelandic the double ell makes it fall-hat-la.

Languages are cool!

Post reply on HN