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

Go has added Valgrind support

go-review.googlesource.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Go has added Valgrind support

#71

Post by bracewel »

Author of the linked CL here: we added this mostly so that we could abuse the memory initialization tracking to test the constant-time-ness of crypto code (similar to what BoringSSL does, proposed by agl around fifteen years ago: https://www.imperialviolet.org/2010/04/01/ctgrind.html), which is an annoyingly hard property to test.

We're hoping that there are also a bunch of other interesting side-effects of enabling the usage of Valgrind for Go, in particular seeing how we can use it to track how the runtime handles memory (hopefully correctly!)

edit: also strong disclaimer that this support is still somewhat experimental. I am not 100% confident we are properly instrumenting everything, and it's likely there are still some errant warnings that don't fully make sense.

Re: Go has added Valgrind support

#72

Post by ben-schaaf »

stingraycharles wrote: post #53
rwmj wrote: post #51

Valgrind is a hidden super-power. In much of the software I write, there's 'make check' which runs the test cases, and 'make check-valgrind' that runs the same test cases under valgrind. The latter is only used on developer machines. It often reveals memory leaks or other subtle memory bugs.

Somewhat yes, but as soon as you enter the world of multi-threading (which Go does a lot), the abstraction doesn’t work anymore: as I understand it (or rather, understood: last time I really spent a lot of time digging into it with C++ code was a while ago) it uses its own scheduler, and as such, a lot of subtle real world issues that would arise due to concurrency / race conditions / etc do not pop up in valgrind. A…

IME Helgrind does an great job finding concurrency issues.

Re: Go has added Valgrind support

#74

Post by tasn »

This feels more like a failure than a win.

Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the fact that Go needs Valgrind feels like a failure of the language or the ecosystem. I've been doing Rust for ~6 years now, and haven't had to reach for Valgrind even once (I think a team member may have use it once).

I realize that's probably because of cgo, and maybe it's in-fact a step forward, but I can help but feel like it is a step backwards.

Re: Go has added Valgrind support

#75

Post by pjmlp »

tasn wrote: post #74

This feels more like a failure than a win. Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the fact that Go needs Valgrind feels like a failure of the language or the ecosystem. I've been doing Rust for ~6 years now, and haven't had to reach for Valgrind even once (I think a team member may have use it once). I realize that's probably because of cgo, an…

Depends on how much unsafe you actually happen to write, use unsafe crates, or link into C and C++ libraries.

I also seldom need something like this in Java, .NET or node, until a dependency makes it otherwise.

Re: Go has added Valgrind support

#76

Post by tasn »

DishyDev wrote: post #70

Very cool. Should flush out a few bugs. I'd be interested to know why Valgrind vs the Clang AddressSanitizer and MemorySaniziter. These normally find more types of errors (like use-after-return) and I find it significantly faster than Valgrind.

Go doesn't use clang/llvm, so they can't use these tools.

Re: Go has added Valgrind support

#77

Post by bracewel »

tasn wrote: post #74

This feels more like a failure than a win. Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the fact that Go needs Valgrind feels like a failure of the language or the ecosystem. I've been doing Rust for ~6 years now, and haven't had to reach for Valgrind even once (I think a team member may have use it once). I realize that's probably because of cgo, an…

This is mainly actually for testing constant-time code, rather than doing proper memory tracking (see https://www.imperialviolet.org/2010/04/01/ctgrind.html for a slightly out-of-date description of this technique).

Re: Go has added Valgrind support

#78

Post by pjmlp »

thechao wrote: post #56
pjmlp wrote: post #48

Earlier quoted context omitted.

It would be another scenario to use as ammunition for "see you can't implement a language toolchain without using C" , usually voiced by folks without background in compiler design, and understanding that most of the time that is a decision that spurs out of convenience and nothing else. Assembly isn't that hard, those of us that grown around 8 bit home computers were writing Z80 and 6502 Assembly aged 10 - 12 years…

Oh. There was a comment to your comment saying that kids learning assembly was easy and — I guess? — implying that adults-learning-assembly is hard. I teach adults assembly on an irregular basis. Adults-learning-assembly is hard because adults are rational animals who (correctly) assume I'm an idiot for insisting on assembly. Once I explain the long-term benefits for our exceedingly specific use case, they pick up as…

I guess because there is nowadays a misconception that it is harder than it actually is in practice.

Exactly, plus one gets to understand what JIT and AOT toolchains are actually generating.

Re: Go has added Valgrind support

#79

Post by tasn »

pjmlp wrote: post #75
tasn wrote: post #74

This feels more like a failure than a win. Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the fact that Go needs Valgrind feels like a failure of the language or the ecosystem. I've been doing Rust for ~6 years now, and haven't had to reach for Valgrind even once (I think a team member may have use it once). I realize that's probably because of cgo, an…

Depends on how much unsafe you actually happen to write, use unsafe crates, or link into C and C++ libraries. I also seldom need something like this in Java, .NET or node, until a dependency makes it otherwise.

For sure, that's why I said it's possibly due to the ecosystem. We link against two C libraries other than libc: OpenSSL and librdkafka. Though they are both abstracted away with solid Rust bindings so for us, so as a consumer of these libs it hasn't been a problem (I guess it may be a problem for the people developing them).

I guess maybe the failure is not the addition of it (as it's useful for people writing the bindings), but rather how happy everyone on the thread is (which means it's more useful than it should be due to a failure with the ecosystem).

Re: Go has added Valgrind support

#80

Post by pjmlp »

tasn wrote: post #76
DishyDev wrote: post #70

Very cool. Should flush out a few bugs. I'd be interested to know why Valgrind vs the Clang AddressSanitizer and MemorySaniziter. These normally find more types of errors (like use-after-return) and I find it significantly faster than Valgrind.

Go doesn't use clang/llvm, so they can't use these tools.

TinyGo does, but it is also behind in language support.
Post reply on HN