Hacker News new | ask | show | jobs
by stingraycharles 268 days ago
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. And the performance penalty in general is very heavy.

Having said that, it saved my ass a lot of times, and I’m very grateful that it exists.
3 comments
acidx 268 days ago
I wrote the Lwan web server, which similarly to Go, has its own scheduler and makes use of stackful coroutines. I have spent quite a bit of time Valgrinding it after adding the necessary instrumentation to not make Valgrind freak out due to the stack pointer changing like crazy. Despite a lot of Valgrind's limitations due to the way it works, it has been instrumental to finding some subtle concurrency issues in the scheduler and vicinity.

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.

link
ben-schaaf 268 days ago
IME Helgrind does an great job finding concurrency issues.
link
cozzyd 268 days ago
Yes though last I tried to use it it sadly didn't support openmp. Maybe that's fixed now (that was a while ago)

(I think it was possible to use on openmp if you compiled your compiler with special options)

link
hedora 267 days ago
tsan from LLVM works a bit better in my experience. I still like valgrind in general though!
link
rwmj 267 days ago
For fuzzing we don't use valgrind, but use Clang + ASan instead. All these tools have their niches.
link
cyphar 267 days ago
TSAN is not perfect but Go has had built-in TSAN support for a very long time (go build -race).

Also, strictly speaking all Go programs are multithreaded. The inability to spawn a single-threaded Go program is actually a huge issue in some system tools like container runtimes and requires truly awful hacks to work around. (Before you ask, GOMAXPROCS=1 doesn't work.)

link