Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by 0x0 | Hacker News Reader

Full thread

0x0·

Does this mean every single application binary compiled with go in the wild up until today has a memory corruption bug?

If so, it's going to take some effort for this bug to be weeded out in every single deployment around the world...

View on HN

From the commit message:

"This bug has existed since Go 1.4. Until then the select code was implemented in C, 'done uint32' was a C stack variable 'uint32 done', and C stacks never moved."

It'll affect probably most running jobs out there, as Go 1.4 was released on Dec 10, 2014.

I don't understand this comment, are you implying that it's the first time you see a runtime with a bug?

Well usually you can just update whatever library has the bug and restart your applications, but as I understand this bug will be statically linked in all application binaries so they will all have to be recompiled and redeployed?

Yes, that's what the grandparent is saying, this is a bug in the runtime, which you can't fix by updating libraries, you have to update the compiler/interpreter (depending on the language).

This is not a unique occurrence.

I think the original question was querying if the runtime is statically or dynamically linked.

It's also possibly a subtle dig at go, because unlike other languages go does not use dynamic linking, meaning bugs in libraries require recompilation (has positive effects too).

Yes it does, since Go 1.6.

It just isn't the default compilation mode, you have to explicitly enable it.

Runtimes have bugs but normally you just download a new one and swap it out.

The bug was introduced in Go 1.5 (when the compiler was rewritten to Go)

No, it was introduced in Go 1.4, when the runtime was rewritten in Go.

Reply on news.ycombinator.com