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.
Go has added Valgrind support
51–60 of 157 posts
Re: Go has added Valgrind support
#52Earlier 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…
[deleted]
Re: Go has added Valgrind support
#53Valgrind 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. 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.
Re: Go has added Valgrind support
#54looks 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
> constant memory leaks/pressure
In Go, never launch a goroutine that you don't know exactly how it will be cleaned up.
Re: Go has added Valgrind support
#55oh man. you came at the right time.
Re: Go has added Valgrind support
#56Earlier 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…
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 assembly in a few hours. Assembly isn't hard. Assembly is annoying because it takes absolutely gobsmacking amounts of assembly to do anything.
Re: Go has added Valgrind support
#57That's quite nice. There is a small risk that the client request mechanism might change . The headers don't change much - mostly when a new platform gets added. Go is only targeting amd64 and arm64.
This isn't so much about leaks. The most important thing that this will enable is correct analysis of uninitialised memory. Without annotation memory that gets recycled will not be correctly poisoned. I imagine that it will also be useful for the other tools (except cachegrind and callgrind).
Re: Go has added Valgrind support
#58Earlier 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…
To the deleted sibling comment about children vs. adults: some children are also optimists.
Re: Go has added Valgrind support
#59Earlier 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…
> it takes absolutely gobsmacking amounts of assembly to do anything.
"ever built something big in LEGO? Yeah? Yeah."
Re: Go has added Valgrind support
#60[deleted]