-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: FreeBSD, OpenBSD ARM builders failing with SIGBUS #15902
Comments
CC @randall77 |
This is a problem at the intersection of tinyalloc, zeroing code, and alignment faults.
Those are 4-byte writes there, but mallocgc is returning something that isn't 4-byte aligned. It is doing that because [10]byte is tiny-allocatable, so sometimes we get an allocation some way into a 16-byte tinyalloc chunk. The fix should be to do zeroing correctly, respecting the possible alignment of the type. Nagging questions TBA: |
Before the liveness change, we relied on newobject to return zeroed memory, so the compiler did not generate code to zero it again. After the liveness change, the compiler emits a useless zeroing. Bad, but not fix-for-go1.7 bad. The zeroing-generating code itself is to blame. |
My understanding is Linux on ARM supports emulating unaligned memory accesses (to make porting programs from x86 easier), and it's possible the builders have that option enabled. I don't believe OpenBSD implements that emulation, and it seems likely that FreeBSD doesn't either. |
Fix mailed (CL 23587) I added a test. If anyone has access to a freebsd/arm box, please try the test without this CL and see if it breaks. It should. I'm kind of baffled as to how freebsd/arm ever used to work before the fix - I guess we just don't ever zero unaligned memory. |
CL https://golang.org/cl/23587 mentions this issue. |
@randall77 I think only tinyalloc ever returns unaligned memory, and it's always zero'd. |
Right, but see my test, it isn't just malloc where we zero memory. |
@randall77 Hm, yeah, that is baffling. |
Keith, Linux/arm doesn't fault on unaligned memory access, you just pay the On Wed, 1 Jun 2016, 08:08 Matthew Dempsky notifications@github.com wrote:
|
I ran the test with
same with tip
And just before http://golang.org/cl/23393
Applying CL https://golang.org/cl/23587 fixes it. |
FreeBSD failures usually look like this:
OpenBSD failures look like this (net/http tests):
And also occasional happens on the FreeBSD builder:
I suspect http://golang.org/cl/23393 is the cause because it looks like the first occurrence on the OpenBSD builder:
https://build.golang.org/log/b75786ad6add5fe0116889706211d1e8faea9df5
With the FreeBSD builder being a bit more flaky, it starts happening after the e9228dd commit.
The text was updated successfully, but these errors were encountered: