|
From: Albert S. <fu...@gm...> - 2011-07-28 20:57:54
|
Hello On Thu, Jul 28, 2011 at 10:46 PM, Alexander Potapenko <gl...@go...> wrote: > Running the binaries under Nullgrind (valgrind --tool=none) is better > to start with, because Go programs are likely to trigger some > incompatibilities in the Valgrind runtime itself, not necessarily > Memcheck. Thanks. I can successfully run all of the Go test programs I tried with Nullgrind. > For example, goroutines may be tricky to mirror in a straightforward > way (using threads), because there can be thousands of them, while > Valgrind has a strict limit for the number of threads. Go also spawns threads. Valgrind probably shouldn't have care about goroutines. > Second, they use segmented stacks in Go, which are extended if needed. > Valgrind does not know about this and may be confused (I suppose the > segfaults in your report could denote the demand for increasing the > stack size) Valgrind does say: ==20554== Warning: client switching stacks? SP change: 0x7ff000440 --> 0x4841fb8 ==20554== to suppress, use: --max-stackframe=34267194504 or greater ==20554== Warning: client switching stacks? SP change: 0x4841f68 --> 0x7ff000470 ==20554== to suppress, use: --max-stackframe=34267194632 or greater ==20554== Warning: client switching stacks? SP change: 0x7ff0003f0 --> 0xf84000f050 ==20554== to suppress, use: --max-stackframe=1031882730592 or greater ==20554== further instances of this message will not be shown. but I still have to read through the documentation of --max-stackframe and friends more carefully. > A side question: is there any particular reason you need Valgrind for Go? Go programs can use C libraries through something called cgo. I'd like to be able to check this C code inside my Go binaries. Also, Valgrind might be able to find bugs in the C part of the Go runtime (goroutine scheduler, garbage collector, etc.). Regards Albert |