91–100 of 157 posts
The older I get the more I value commit messages. It's too easy to just leave a message like "adding valgrind support", which isn't very useful to future readers doing archaeology.
Earlier quoted context omitted.
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 b…
More likely Go users are just happy in general. The Rust users always come across as being incredibly grumpy for some reason, which may be why that happiness — or what would be considered normalcy in any other venue — seems to stand out so much in comparison.
> We link against [...] OpenSSL
Which is kind of funny as Valgrind support was added specifically for the crypto package to help test tricky constant-time cases. You think that the failure of the ecosystem is that Go has built high-quality crypto support in rather than relying on the Heartbleed library instead...? That is certainly an interesting take.
Not even a Go user, and yet this is one of the best things I have read today morning. Valgrind is possibly one of the most powerful tools I have in my belt!!
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…
Also, assembly is complex because each instruction is very simple.
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…
From a quick glance, it seems that Go is now registering the stacks and emitting stack change commands on every goroutine context switch. This is most likely enough to make Valgrind happy with Go's scheduler.
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.
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…
no, haven't heard of goref yet but will give it a shot! usually I go with pprof, like basic stuff and it helps. I would NOT say memory leak is the biggest or most common issue I see, however as time goes and services become more complicated what I often see in the metrics is how RAM gets eaten and does not get freed as time goes, so the app eats more and more memory as time goes and only restart helps. It's hard to c…
Also, are you running the code in a container? In K8s?
looks very promising, one of the biggest issue in golang for me is profiling and constant memory leaks/pressure. Not sure if there is an alternative of what people use now
How are you getting "constant memory leaks" in a GC'd language?
Earlier quoted context omitted.
How are you getting "constant memory leaks" in a GC'd language?
it's not hard. GC lets shit leak until it decided to clean it up... do you think they will enable Valgrind if there's no leaks?
uninitialized memory, illegal writes, etc... There's a lot of good stuff that could be discovered.
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…
I never understand why there's always one of the top comment on every Go post being derogatory and mentioning Rust. It never fails. It starts to feel like a weird mix of defensiveness and superiority complex.