-
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
runtime: aix-ppc64 builder is failing with "bad prune", "addr range base and limit are not in the same memory segment" fatal errors #38966
Comments
Ah, the CC @Helflym |
I think the problem comes from the fact that Note that I don't really understand how the check is working inside |
@Helflym x86 has a split/discontiguous address space, and the purpose of
|
I confirm, setting these values for |
I think the correct value for CC @aclements @prattmic for additional opinions (optional). |
I think all of this is quite confusing, and the documentation doesn't help: "arenaBaseOffset is the pointer value that corresponds to index 0 in the heap arena map." - https://cs.opensource.google/go/go/+/master:src/runtime/malloc.go;l=290 Unless I am misreading that sentence, it is asserting that x86, Linux: AIX: I believe what it should say is: "arenaBaseOffset is the offset such that arena index zero corresponds to the minimum valid virtual address. i.e., arenaBase(0) == minimum valid virtual address" This property actually holds true: x86, Linux: AIX: From With this clarified, I think it makes much more sense to define minOffAddr and maxOffAddr explicitly: x86: AIX: And then have (As an aside, I think the most recent docs on offAddr are a bit confusing because they say that is "is" an offset address. Except it's just stored as a normal address. It is the methods (less, greater) that treat ordering as though it is offset.) |
Agreed, that documentation is wrong. This should all be updated.
Admittedly, this part was kind of a hack... :( Ideally we'd like to just treat AIX's address space as a 60-bit address space, but that would require making fairly large mappings for both the page allocator and the arena index. Unfortunately, the application slows to a crawl when a large mapping is made (we're not exactly sure what goes wrong).
That all makes sense to me.
Also agreed. It's technically true if you don't construct an I'll put up a CL that fixes this issue and does some additional cleanup in the documentation. |
Change https://golang.org/cl/233497 mentions this issue: |
@prattmic Actually, this isn't directly feasible. Also taking a step back: while I agree the definition of I've uploaded the CL, let me know what you think! |
Currently maxOffAddr is defined in terms of the whole 64-bit address space, assuming that it's all supported, by using ^uintptr(0) as the maximal address in the offset space. In reality, the maximal address in the offset space is (1<<heapAddrBits)-1 because we don't have more than that actually available to us on a given platform. On most platforms this is fine, because arenaBaseOffset is just connecting two segments of address space, but on AIX we use it as an actual offset for the starting address of the available address space, which is limited. This means using ^uintptr(0) as the maximal address in the offset address space causes wrap-around, especially when we just want to represent a range approximately like [addr, infinity), which today we do by using maxOffAddr. To fix this, we define maxOffAddr more appropriately, in terms of (1<<heapAddrBits)-1. This change also redefines arenaBaseOffset to not be the negation of the virtual address corresponding to address zero in the virtual address space, but instead directly as the virtual address corresponding to zero. This matches the existing documentation more closely and makes the logic around arenaBaseOffset decidedly simpler, especially when trying to reason about its use on AIX. Fixes golang#38966. Change-Id: I1336e5036a39de846f64cc2d253e8536dee57611 Reviewed-on: https://go-review.googlesource.com/c/go/+/233497 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
I'm puzzled about what happened in this issue. It's still open, yet I see CL 233497 was merged on May 14th into the main Go repo with the text "Fixes #38966", which is this very issue. Yet it never got closed? (That CL caused #39128, which was fixed via roll-forward.) Maybe GitHub had an service disruption that caused the "Fixes #38966" event get skipped somehow. @mknyszek Can you confirm this issue should be closed now, or am I missing something? Thanks. |
@dmitshur Yeah this should be closed, I think. It should've been closed with that CL, not sure what happened. Closing now... |
The
aix-ppc64
builder has started to fail on build.golang.org continuously sinceb1a48af or55ec518. The errors look like:It's unclear to me if one of the CLs has started to cause this, or if the builder has a problem. Needs investigation.Edit: @mknyszek has narrowed it down, see comment below.
Previously, a flaky failure in net/http made it harder to tell where the problem was:
/cc @trex58 @mknyszek @mvdan
The text was updated successfully, but these errors were encountered: