x/mobile: Binding go mobile framework on iOS 9 with golang1.7rc6 crash when call debug.FreeOSMemory() #16644
Comments
|
I'm seeing a random crash from time to time as well. I'll confirm if it is the same. /cc @crawshaw |
|
I think this bug is emergency for me. If the golang team do not fix this bug before ios10 public release.I have to fix it myself after ios10 public release in the golang source code, and maintain my own version of golang. |
|
cc @aclements @RLH for the runtime crash @bronze1man Do you see the crash when running the app without XCode? With XCode, can you replicate the crash with |
|
@crawshaw I do not know how to run the app without XCode. xcode also get some asm code: |
|
Could you display the value of the R0 register at the time of crash? Looks
like the madvise syscall is returning some errors and I'd like to know
which.
A safe fix is to disable FreeOSMemory on iOS or ignore the error from
madvise (which effectively disabled FreeOSMemory too)
|
|
"A safe fix is to disable FreeOSMemory on iOS or ignore the error from I think that disabling FreeOSMemory is not an option for me. |
|
I need to know at least the error code to diagnose the problem. (R0
register value as I mentioned in my last reply.)
Note that FreeOSMemory doesn't guarantee returning memory to the OS.
|
|
One possibility is the page size issue. Do you know the page size iOS 10
uses?
|
|
|
Thanks. 0x16 means EINVAL.
We're already using 64K physical pages (which is bigger than
darwin/amr64 default page size of 16KB, I don't think it's due to
page size issues. madvise man pages showed the following
two causes for EINVAL:
[EINVAL] The value of advice is incorrect.
[EINVAL] The address range includes unallocated regions.
I'm puzzled by this. Perhaps iOS 10 doesn't support MADV_FREE
anymore? Will need to get access to iOS 10 to further debug this...
In the mean time, could you dump the first few 64-bit words that
sp points to? I'd like to see the address is indeed 64KB aligned
to rule out the page size issue.
|
|
If you need a workaround, you can apply the patch for time.Now to Go 1.6; I believed it should apply cleanly. |
|
"I'm puzzled by this. Perhaps iOS 10 doesn't support MADV_FREE |
Then I add one line here: Then I got following from xcode: So I found the reason of EINVAL, The value of advice is incorrect. let's print again: Then I got following: |
|
I found a patch that can fix my first test case: This patch also make the app which uploaded to appStore works. |
|
I'm even more puzzled. Why decreasing PhysPageSize fixes
the problem? With higher PhysPageSize, we always align
the address to madvise using the higher value, which should
also be aligned to any smaller power-of-two too.
Am I missing something?
|
|
I'm seeing a similar bug (notok crashes on go 1.7 rc6). However, I'm not calling FreeOSMemory. This is (unfortunately) in the wild, so I have a wealth of crash reports in Crashlytics (hundreds). Details:
|
|
I can't work out why a smaller PhysPageSize would fix this either. But if it does, we could set it just for iOS. |
|
this is the crash we are getting randomly, not sure if it is related: |
|
"I can't work out why a smaller PhysPageSize would fix this either. But if it does, we could set it just for iOS." |
@bronze1man, this is very helpful. Could you try changing mheap.go line 920 to say "if start >= end" (and reverting your change to PhysPageSize)?
Note that Go 1.6 simply never used MADV_FREE or returned memory to the OS on ARM64. That's all new in Go 1.7.
@minux, I think the rounding check at mheap.go:920 is wrong (oops). Decreasing PhysPageSize to 8K makes the rounding a no-op, which covers up the bad check. |
|
I mailed https://go-review.googlesource.com/27230, which implements the "if start >= end" fix I asked @bronze1man to try. @scosman, would you also be able to try this change? I don't know if you can reproduce it locally.
@scosman, if this is what I think it is, FreeOSMemory isn't necessary. FreeOSMemory forces the scavenger to run, but it runs on its own periodically and will start releasing memory after it's gone unused for ~5 minutes.
@crawshaw, it's not safe to reduce PhysPageSize below the actual physical page size of the system (see #9993). I don't know what the actual physical page size of iOS on ARM64 is. (https://go-review.googlesource.com/25022 will make the runtime fetch this from the OS, but I wouldn't want to put that in 1.7.) Plus, if I understand this bug, reducing it to anything more than 8K won't fix it. |
|
CL https://golang.org/cl/27230 mentions this issue. |
|
@aclements I cherry-picked 25022 on top of the release-branch.go1.7 branch, but I reproduced the issue with that build. Again, not sure it's the same issue, but it does sound similar. As you mentioned, I need to wait a few minutes (with the app in the background) to repro. Stack trace Test App`notok:
0x10077fc28 <+0>: movz x8, #0
-> 0x10077fc2c <+4>: str x8, [x8]
0x10077fc30 <+8>: b 0x10077fc30 ; <+8>
0x10077fc34 <+12>: .long 0x00000000 ; unknown opcode
|
|
Sorry for not replying in time.I just have other stuff to do. Following patch works for me: My first test case and the bigger app both work. |
|
@dcu I don't think your "runtime: unexpected return pc..." crash is related. Please file a new issue for that. Thank you. |
|
@eliasnaur I created #16760 I'm sorry I don't have an easy way to reproduce the error |
|
@bronze1man, great! I'll push that fix shortly and it should appear in Go 1.7.1 (which we already have a few bugs for, so I suspect that won't be too far off). @scosman, it sounds like you have a different bug, then. The crash in "notok" just means some system call failed, which could have any number of causes. Could you open a new bug and CC me, @minux, and @crawshaw? Please include any additional information you have. Unfortunately, the one stack frame isn't enough to figure much out. More frames would be great. Even just a dump of the registers would be helpful. |
|
I do not think this bug is fixed totally. |
|
@bronze1man, I'm sorry, but I don't understand what "other situation" you mean. What bugs in "start" and "end" are you referring to?
Smaller. Specifically, we need the 64KB-aligned range that is contained in the range [start, end). It was possible to get a negative range because we compute this by rounding start up to the next 64KB boundary and end down to the previous 64KB boundary. If they're already in the same 64KB region, this can cause start and end to cross over, leading to the negative range. |
|
@aclements Thanks, I got it. |
The previous fix for this, commit 336dad2, had everything right in the commit message, but reversed the test in the code. Fix the test in the code. This reversal effectively disabled the scavenger on large page systems *except* in the rare cases where this code was originally wrong, which is why it didn't obviously show up in testing. Fixes #16644. Again. :( Change-Id: I27cce4aea13de217197db4b628f17860f27ce83e Reviewed-on: https://go-review.googlesource.com/27402 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
@aclements FYI, I won't open the issue as you requested because I retested the patch and couldn't repro that issue. I must have tested with the wrong file :(. Thanks! |
|
CL https://golang.org/cl/28631 mentions this issue. |
…ounding again The previous fix for this, commit 336dad2, had everything right in the commit message, but reversed the test in the code. Fix the test in the code. This reversal effectively disabled the scavenger on large page systems *except* in the rare cases where this code was originally wrong, which is why it didn't obviously show up in testing. Fixes #16644. Again. :( Change-Id: I27cce4aea13de217197db4b628f17860f27ce83e Reviewed-on: https://go-review.googlesource.com/27402 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-on: https://go-review.googlesource.com/28631 Run-TryBot: Chris Broadfoot <cbro@golang.org>
Please answer these questions before submitting your issue. Thanks!
go version)?go version go1.7rc5 darwin/amd64
go env)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH=""
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m9/qtbxkp6s3p96fk54rln7qhj80000gp/T/go-build097177340=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
I create a simple one page ios project.
I write a simple package with follow code:
change the ViewController.m with follow code:
I build the framework with follow code(the kmg stuff should be easy to understand):
see following in ios console:
see following in ios console:
and crash with EXC_BAD_ACCESS
gomobile version
ios version: 9.0.2
ios device name: iphone 6s
It works ok with golang1.6.
I have uploaded several apps with gomobile and golang1.6 to apple app store.
I can use golang1.6 to work around this problem.
This issue may be same as #16598
The text was updated successfully, but these errors were encountered: