We found a bug in Go's ARM64 compiler • Hacker News Board

Re: We found a bug in Go's ARM64 compiler

#141

Post by pengaru » Fri, Oct 10, 2025, 12:09 AM UTC

jimsmart wrote: post #139

chavi2 wrote: post #91

Earlier quoted context omitted.

One thing I worry about, probably unnecessarily, is anything with a sense of urgency. HEY GUYS WE JUST FOUND A GOLANG COMPILER BUG AND FATAL PANICS! Everyone is like “Hmm. I need to fix this now.” So, 99% probability it’s what it is. 1% it’s some secret defensive thing because there was a bad stupid zero day someone would get fired over or that could leave the world in shambles if uncovered, or maybe something else n…

It's an open source project — and quite a popular one, at that — and you are literally replying to a comment that specifies the changes made to fix this particular issue — you can see for yourself what is occurring here. Anyone can. This issue, and the fix, has perfectly good visibility. Even if you personally can't understand the code, plenty of others can and do. All of which makes your claims seem like quite unnec…

the account was created 22 hours ago, it's pointless to engage

Re: We found a bug in Go's ARM64 compiler

#142

Post by btbuilder » Fri, Oct 10, 2025, 2:32 PM UTC

afdbcreid wrote: post #101

btbuilder wrote: post #67

Earlier quoted context omitted.

Segfaults with no use of “Unsafe” equivalents in managed languages can give immediate indication it’s not a code problem.

They explicitly mention there was usage of unsafe, and they weren't sure that's not the cause.

Right, in a 3rd-party library.

Re: We found a bug in Go's ARM64 compiler

#143

Post by pfdietz » Fri, Oct 10, 2025, 2:51 PM UTC

syncsynchalt wrote: post #99

pfdietz wrote: post #78

I see something like this and I wonder "what testing methodology would have found this?" It has to be general, not something that would involve knowing what the bug was ahead of time.

When your scale is large enough, you move to "what monitoring methodology will find this?" When you're doing enough transactions you start to see a noise floor of e.g. bit flips from cosmic rays, and looking for issues involves correlating/categorizing possible software failures and distinguishing them from the misbehavior of hardware.

I meant, what testing methodology could the compiler writers have used, so it was caught before it went to users.

The feedback loop here should be: novel bug comes in ==> determine how existing testing was deficient ==> modify the testing in a general way that would have found this bug ==> run these modified tests in the background to see if anything similar was missed. Bugs should be used as indicators that regions (as large as possible) of bug space have been inadequately covered.

Re: We found a bug in Go's ARM64 compiler

#144

Post by maguro_01 » Sun, Oct 12, 2025, 6:32 AM UTC

An x86-64 Windows 11 machine trying to access a previously available Website now always produces a Cloudflare "obsolete protocol" error on the ordinary attempt. Al browsers get the same error. Did your fix break something?

Re: We found a bug in Go's ARM64 compiler

#145

Post by maguro_01 » Sun, Oct 12, 2025, 6:33 AM UTC

maguro_01 wrote: post #144

An x86-64 Windows 11 machine trying to access a previously available Website now always produces a Cloudflare "obsolete protocol" error on the ordinary attempt. Al browsers get the same error. Did your fix break something?

Sorry, all browsers.

Re: We found a bug in Go's ARM64 compiler

#146

Post by peterfirefly » Mon, Oct 13, 2025, 9:39 PM UTC

pjmlp wrote: post #106

Vipsy wrote: post #103

One thing that often gets missed is how hard it is to even suspect the compiler as the root cause. Most engineers waste hours chasing bugs in their own code because we’re trained to trust our tools. This mindset alone can make these rare compiler bugs much trickier to find.

In the early PC days we suspected them a lot given how manually writting Assembly was still much better, in many cases. I found out a bug on Turbo Pascal 6, where if you declare a variable with the same name as the function name, then the result was random garbage. For those that don't know Pascal, the function name has to be assigned for the result value, so if a local variable with the same name is possible, then y…

succ(seg(x)) and pred(seg(x)) turned out to be equivalent of just seg(x) in TP6.

Earlier versions of Turbo Pascal (and Poly Pascal) generated poor code for "... + 1" but better code with succ(...) and doing memory access via memw[s:o] was common for speed for certain kinds of code. Allocating whatever size you needed + 16 guaranteed you had allocated enough to have paragraph aligned allocation (16 instead of 15 so you could just use the segment + 1).

I think it took a day or two to find this bug in some text-mode windowing code I'd written.