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

61–70 of 157 posts

Re: Go has added Valgrind support

#61

Post by felixge »

tsimionescu wrote: post #33
felixge wrote: post #5

Earlier quoted context omitted.

I'd love to hear more! What kind of profiling issues are you running into? I'm assuming the inuse memory profiles are sometimes not good enough to track down leaks since they only show the allocation stack traces? Have you tried goref [1]?. What kind of memory pressure issues are you dealing with? [1] https://github.com/cloudwego/goref Disclaimer: I work on continuous profiling for Datadog and contribute to the profi…

I for one am still mystified how it's possible that a GC language can't expose the GC roots in a memory profile. I've lost so many hours of my life manually trying to figure out what might be keeping some objects live, information the GC figures out every single time it runs...

Do you think the GC roots alone (goroutine stacks with goroutine id, package globals) would be enough?

I think in many cases you'd want the reference chains.

The GC could certainly keep track of those, but at the expense of making things slower. My colleagues Nick and Daniel prototyped this at some point [1].

Alternatively the tracing of reference chains can be done on heap dumps, but it requires maintaining a partial replica of the GC in user space, see goref [2] for that approach.

So it's not entirely trivial, but rest assured that it's definitely being considered by the Go project. You can see some discussions related to it here [3].

Disclaimer: I contribute to the Go runtime as part of my job at Datadog. I can't speak on behalf of the Go team.

[1] https://go-review.googlesource.com/c/go/+/552736

[2] https://github.com/cloudwego/goref/blob/main/docs/principle....

[3] https://github.com/golang/go/issues/57175

Re: Go has added Valgrind support

#63

Post by aleksi »

johncolanduoni wrote: post #31
aleksi wrote: post #24

Earlier quoted context omitted.

> If you have a struct with a simple int field, and you store that somewhere as an *int, the entire struct and anything it points to will be kept alive. While Go allows interior pointers, I don't think what you say is true. runtime.KeepAlive was added exactly to prevent GC from collecting the struct when only a field pointer is stored. Take a look at this blog post, for example: https://victoriametrics.com/blog/go-ru…

I don’t believe that’s the case based on the example in the blog post. The fd field in that struct was passed into the later function by value (i.e. as an int, not an *int), so there was no interior pointer in play at all.

You are right; I stand corrected

Re: Go has added Valgrind support

#64

Post by styluss »

Thaxll wrote: post #47
defraudbah wrote: post #37

Earlier quoted context omitted.

yes, that's what I use, just wonder if there are alternatives. I am not sure how valgrind compares to it or the goref tool mentioned above, just asking around, does not hurt.

Alternative to solve what problem? pprof is very powerful, it's not missing much.

Pprof doesn't tell you if something was leaked aka still around.

I fixed a leak recently because of misuse of a slice with code like

slice = append(slice[1:], newElement)

I only figured it out by looking at the pprof heap endpoint output and noticed there were multiple duplicate entries.

Re: Go has added Valgrind support

#65

Post by fragmede »

pjmlp wrote: post #48
giancarlostoro wrote: post #20

Earlier quoted context omitted.

I am still curious, had they not gone this route, and avoided the other two routes mentioned, what could they have done to make this process as simple as the rest of Go tends to be, and nearly as performant? I guess this is an ongoing question to be solved at a future date.

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…

Z80 on the TI-80 series of calculators for me. The Internet was very young, but there was ticalc.org. Damn, it's still around. I wonder if can log in?

Re: Go has added Valgrind support

#66

Post by fragmede »

amelius wrote: post #40
sauercrowd wrote: post #29

Earlier quoted context omitted.

it's a rejection of the thesis that it "does not work". It does, but it requires investing into a suppression file.

Yeah I tried that on a PySide6 application. Trust me, it does not work.

skill issue

Re: Go has added Valgrind support

#67

Post by dec0dedab0de »

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…

Do you have anything public on how you get people writing assembly in a few hours?

Re: Go has added Valgrind support

#69

Post by frollogaston »

giancarlostoro wrote: post #28
preisschild wrote: post #12

Earlier quoted context omitted.

And yet it's mature enough to be used for highly critical software such as Kubernetes...

Good enough to be used by every major cloud provider, every time you download Google Chrome, and Android SDKs you pull from a standard library Go based HTTP server.

How do you know the Chrome downloads server specifically is written in Go?

Re: Go has added Valgrind support

#70

Post by DishyDev »

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.

Post reply on HN