2 ms·

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 f

by 0x0 10y ago

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...

msiebuhr 10y ago
The bug was introduced in Go 1.5 (when the compiler was rewritten to Go)
- mseepgood 10y ago
  No, it was introduced in Go 1.4, when the runtime was rewritten in Go.
deleted 10y ago
[deleted]
Thaxll 10y ago
I don't understand this comment, are you implying that it's the first time you see a runtime with a bug?
- 0x0 10y ago
  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?
  - Manishearth 10y ago
    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.
    - wonko1 10y ago
      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).
      - pjmlp 10y ago
        Yes it does, since Go 1.6. It just isn't the default compilation mode, you have to explicitly enable it.
- zigzigzag 10y ago
  Runtimes have bugs but normally you just download a new one and swap it out.
kyrra 10y ago
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.

by 0x0 10y ago

msiebuhr 10y ago

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

mseepgood 10y ago
No, it was introduced in Go 1.4, when the runtime was rewritten in Go.

deleted 10y ago

[deleted]

Thaxll 10y ago

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

0x0 10y ago
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?
- Manishearth 10y ago
  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.
  - wonko1 10y ago
    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).
    - pjmlp 10y ago
      Yes it does, since Go 1.6. It just isn't the default compilation mode, you have to explicitly enable it.
zigzigzag 10y ago
Runtimes have bugs but normally you just download a new one and swap it out.

kyrra 10y ago

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.