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

111–120 of 157 posts

Re: Go has added Valgrind support

#111

Post by skissane »

gizmo686 wrote: post #43
hu3 wrote: post #41

Earlier quoted context omitted.

plus, LLMs can generate suppressor files from logs. It's much faster these days. I've had success with this approach.

Valgrind can generate suppression files directly.

Yes, but in my past experience, one often wants to be edit those files to make them more generic… Valgrind struggles to distinguish which parts of the call stack are essential to a “known leak” versus which are coincidental.

I have never tried asking an LLM to do this-but it seems like the kind of problem with which an LLM might have some success, even if only partial success.

Re: Go has added Valgrind support

#112

Post by wavemode »

9rx wrote: post #109
tasn wrote: post #106

Earlier quoted context omitted.

If I had to guess: because Rust engineers are like every other engineer that reads HN. They read stories, sometimes comment, and share from their own experience. Rust and Go were created roughly at the same time and are more directly comparable than e.g. Go and Ruby, so you don't see Ruby people writing about not having to use Valgrind. This means you'll see more comments from Rust devs than others in Go threads. At…

> and are more directly comparable than e.g. Go and Ruby Why do you say that? The original Go announcement made it abundantly clear that it was intended to be like a dynamically-typed language, but faster. It is probably more like Python than Ruby, as it clearly took a lot of ideas from Python, but most seem to consider those languages to be in the same hemisphere anyway. Beyond maybe producing complied binaries, whi…

I don't think this is correct. Go is a language with structs, arrays, value semantics and pointers, and an `unsafe` package for performing low-level operations on those pointers and deal directly with the layout of memory. And in practice Go and Rust have found use in a lot of the exact same systems programming and network programming domains, as replacement languages for C.

Go is certainly a higher-level language than C, but to say it's at all similar to Python or Ruby is nonsensical.

Re: Go has added Valgrind support

#113

Post by 9rx »

wavemode wrote: post #112
9rx wrote: post #109

Earlier quoted context omitted.

> and are more directly comparable than e.g. Go and Ruby Why do you say that? The original Go announcement made it abundantly clear that it was intended to be like a dynamically-typed language, but faster. It is probably more like Python than Ruby, as it clearly took a lot of ideas from Python, but most seem to consider those languages to be in the same hemisphere anyway. Beyond maybe producing complied binaries, whi…

I don't think this is correct. Go is a language with structs, arrays, value semantics and pointers, and an `unsafe` package for performing low-level operations on those pointers and deal directly with the layout of memory. And in practice Go and Rust have found use in a lot of the exact same systems programming and network programming domains, as replacement languages for C. Go is certainly a higher-level language th…

> Go is a language with structs, arrays

Just like Ruby. Just like pretty much every language people actually use.

> value semantics and pointers

Value semantics are one of the tricks it uses to satisfy the "but faster" part. It is decidedly its own language. But it only supports value semantics, so this is more like Ruby, which only supports reference semantics. Rust supports both value and reference semantics, so it is clearly a very different beast.

> and an `unsafe` package for performing low-level operations on those pointers

The Ruby standard library also includes a package for this.

> And in practice Go and Rust have found use in a lot of the exact same systems programming and network programming domains, as replacement languages for C.

Maybe in some cases, but the data is abundantly clear that Go was most adopted by those who were previously using Ruby and Python. The Go team did think at one point that it might attract C++ programmers, but they quickly found out that wasn't the case. It was never widely adopted in that arena. Whereas I think it is safe to say that many C++ programmers would consider Rust. Which makes sense as Rust is intended to play in the same ballpark as C++. Go was explicitly intended to be a 'faster Python'.

> but to say it's at all similar to Python or Ruby is nonsensical.

Go is most similar to Go, but on the spectrum is way closer to Python and Ruby than it is Rust. It bears almost no resemblance to Rust. Hell, even the "Rustacians'" complaint about Go is that it is nothing like Rust.

Re: Go has added Valgrind support

#114

Post by on_the_beach »

bracewel wrote: post #71

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…

This is super cool. Hopefully it will flush out other issues in Go too.

But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance?

I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS noise) and see how constant they are directly?

Also some CPUs have a counter for conditional branches (that the rr debuger leverages), and you could sample that before and after and make sure the number of conditional branches does not change between decrypts -- as that AGL post mentions branching being the same is important for constant time.

Finally, it would also seem trivial to track the first 10 decrypts, take their maximum time add a small extra few nanoseconds tolerance, and pad every following decrypt with a few nanoseconds (executing noops) to force constant time when it is varying.

And you could add an assert that anything over that established upper bound crashes the program since it is violating the constant time property. I suppose the real difficulty is if the OS deschedules your execution and throws off your timing check...

Re: Go has added Valgrind support

#115

Post by kbolino »

gdbsjjdn wrote: post #39
giancarlostoro wrote: post #25

Earlier quoted context omitted.

Interesting, I always thought of slices as stand-alone, I wonder if its the same in Python?

A go slice is a wrapper around a normal array. When you take sub-slices those also point to the original array. There's a possible optimization to avoid this footgun where they could reallocate a smaller array if only subslices are reachable (similar to how they reallocate if a slice grows beyond the size of the underlying array).

Most sublicing is just the 2-arg kind so it would not be safe to truncate the allocation even if the subslice is the only living slice because the capacity still allows indirect access to the trailing elements of the original slice. This optimization would only be truly safe for strings (which have no capacity) or the much less common 3-arg slicing (and Go would need to have a compacting GC).

Of course, the language could also be changed to make 2-arg slice operations trim the capacity by default, which might not be a bad idea anyway.

Re: Go has added Valgrind support

#116

Post by le-mark »

on_the_beach wrote: post #114
bracewel wrote: post #71

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…

This is super cool. Hopefully it will flush out other issues in Go too. But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS no…

> But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance?

My guess is because the GC introduces pauses and therefor nondetermism in measuring the time anything takes.

Re: Go has added Valgrind support

#117

Post by eschneider »

xmprt wrote: post #94
thechao wrote: post #56

Earlier quoted context omitted.

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…

Assembly is simple because each instruction is very simple. Also, assembly is complex because each instruction is very simple.

Large Scale Assembly puts a huge premium on planning and design. If you try to just bang things out, you'll live in a world of pain.

Re: Go has added Valgrind support

#118

Post by zer00eyz »

moomin wrote: post #110
bear8642 wrote: post #104

Earlier quoted context omitted.

Remember, simple is not the same easy

See also: go.

Well.

Don't try to write "good" go and it becomes easy too.

I would rather see clearly defined, readable, documented code that isnt optimal... than good code lacking any of those traits.

And good code often isnt clearly defined, it often isn't reader friendly and it often lacks documentation (this bit is fixable but ends up needing a lot more of it).

Bad code that works isnt bad.

Re: Go has added Valgrind support

#119

Post by 1718627440 »

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.

Valgrind is way faster and can be attached to a running program.

Re: Go has added Valgrind support

#120

Post by pstuart »

le-mark wrote: post #116
on_the_beach wrote: post #114

Earlier quoted context omitted.

This is super cool. Hopefully it will flush out other issues in Go too. But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? I mean, you want to show constant time of your crypto functions, why not just directly measure the time under lots of inputs? (and maybe background Garbage Collection and OS no…

> But I wonder why its not trivial to throw a bunch of different inputs at your cyphering functions and measure that the execution times are all within an epsilon tolerance? My guess is because the GC introduces pauses and therefor nondetermism in measuring the time anything takes.

I believe that Go can have GC disabled so that issue could be moot.
Post reply on HN