Skip to content
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

x/mobile: iOS apps crash on launch since 1.16 #47952

Open
andydotxyz opened this issue Aug 25, 2021 · 25 comments
Open

x/mobile: iOS apps crash on launch since 1.16 #47952

andydotxyz opened this issue Aug 25, 2021 · 25 comments

Comments

@andydotxyz
Copy link
Contributor

@andydotxyz andydotxyz commented Aug 25, 2021

What version of Go are you using (go version)?

1.16/1.17

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

iOS arm 64

What did you do?

iOS apps, built with Fyne, work on my iOS devices when built with Go 1.14/1.15.
The same apps show but then close immediately if built with 1.16/1.17.

What did you expect to see?

The app should stay running

What did you see instead?

The app becomes visible but then closes.
No log, no crash.

According to Apple developers this seems to be something in Go(mobile) shutting down the app cleanly.

Relates to fyne-io/fyne#2270

@gopherbot gopherbot added this to the Unreleased milestone Aug 25, 2021
@andydotxyz
Copy link
Contributor Author

@andydotxyz andydotxyz commented Aug 25, 2021

I also tried trapping signals

	signal.Notify(sigs, syscall.SIGUSR1, syscall.SIGUSR2, syscall.SIGINT, syscall.SIGTERM, syscall.SIGHUP, syscall.SIGQUIT)

but none of these are triggered

@andydotxyz
Copy link
Contributor Author

@andydotxyz andydotxyz commented Aug 25, 2021

Update: I added a panic to the GOROOT os.Exit call - and that is never logged... So it can't be a clean exit that is happening either!?

@changkun
Copy link
Contributor

@changkun changkun commented Aug 25, 2021

I encountered the exact same problem yesterday, verified the problem still exist in iOS 15 beta 6 (back then I was thinking it might be a beta OS issue, now seems not). Since I was using gomobile for the compilation, it is clear that not an issue triggered by fyne.

A single file reproducer (using gomobile): https://github.com/golang-design/clipboard/blob/main/cmd/gclip-gui/main.go

@andydotxyz
Copy link
Contributor Author

@andydotxyz andydotxyz commented Aug 25, 2021

Thanks for this @changkun I honestly thought it could have been Fyne related for a while or I would have reported it up here sooner. Also knowing that Go 1.17 exhibits the same problem as 1.16 kicked me to dig deeper.

@changkun

This comment has been hidden.

@andydotxyz
Copy link
Contributor Author

@andydotxyz andydotxyz commented Aug 25, 2021

Ah that is interesting. Is there anything we can do to test?

I'm not sure though - the apps do load and show in some cases before terminating, so it can't be completely incompatible.

@changkun
Copy link
Contributor

@changkun changkun commented Aug 25, 2021

After a bisect on the tree with the above example, the issue was introduced in 28e549d .

cc @cherrymui @ianlancetaylor

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 25, 2021

Change https://golang.org/cl/344969 mentions this issue: runtime: use sigaltstack on ios/arm64

@changkun
Copy link
Contributor

@changkun changkun commented Aug 25, 2021

I just sent a CL that should fix the problem.

This is a crash log (after 28e549d):

signal 16 received on thread with no signal stack
fatal error: non-Go code disabled sigaltstack

runtime stack:
runtime: unexpected return pc for runtime.sigtramp called from 0x1f1189c18
stack: frame={sp:0x1300448d0, fp:0x1300449a0} stack=[0x13003c7e8,0x130044be8)
00000001300447d0:  0000000000000020  0000000130044848 
00000001300447e0:  0000000100d74fdc <runtime.sigtrampgo+348>  0000000000000010 
00000001300447f0:  0000000130044818  0000000130044848 
0000000130044800:  0000000130044858  0000000000000000 
0000000130044810:  0000000000000000  0000000000000000 
0000000130044820:  0000000000000000  0000000000000004 
0000000130044830:  0000000000000000  0000000130044848 
0000000130044840:  0000000100d74fb0 <runtime.sigtrampgo+304>  00000001300448c8 
0000000130044850:  0000000100d908f8 <runtime.sigtramp+136>  0000000100000010 
0000000130044860:  0000000100ece2c0  0000000130044888 
0000000130044870:  0000000000000000  0000000000000000 
0000000130044880:  0000000000000000  0000000000000000 
0000000130044890:  0000000000000000  0000000000000000 
00000001300448a0:  0000000000000000  0000000000000000 
00000001300448b0:  0000000130000300  00000001300449d0 
00000001300448c0:  0000000130044a38  00000001300449c0 
00000001300448d0: <00000001f1189c18  0000000000000010 
00000001300448e0:  00000001300449d0  0000000130044a38 
00000001300448f0:  9da526e2cfa9ab7e  0000000130044a38 
0000000130044900:  0000000203721000  0000000100eedc94 
0000000130044910:  0000000100eedc95  0000000100ecdc10 
0000000130044920:  0000000000000018  0000000100eb7fb8 
0000000130044930:  0000000000001690  0000000130000300 
0000000130044940:  00000001300448c8  0000000000000000 
0000000130044950:  0000000000000000  0000000000000000 
0000000130044960:  0000000000000000  0000000000000000 
0000000130044970:  0000000000000000  0000000000000000 
0000000130044980:  0000000000000000  0000000000000000 
0000000130044990:  0000000000000000  0000000000000000 
00000001300449a0: >0000000100eedc94  0000000000000003 
00000001300449b0:  000000000000007d  0000000000000030 
00000001300449c0:  0000000130044e18  e9067f8100d7d3d4 
00000001300449d0:  0000000000000010  0000000000000000 
00000001300449e0:  0000000000000000  0000000100d7d72c <runtime.step+44> 
00000001300449f0:  0000000000000000  0000000000000000 
0000000130044a00:  0000000000000000  0000000000000000 
0000000130044a10:  0000000000000000  0000000000000000 
0000000130044a20:  0000000000000000  0000000000000000 
0000000130044a30:  0000000000000000  0000000000000000 
0000000130044a40:  00000001300449d0  0000000000000000 
0000000130044a50:  0000000000000000  0000000000000000 
0000000130044a60:  0000000000000330  0000000130044a70 
0000000130044a70:  0000000100e70565  0000000092000007 
0000000130044a80:  0000000000000001  0000000000012f3b 
0000000130044a90:  0000000100e70565  0000000000000000 
runtime.throw(0x100de9f03, 0x20)
	/Users/changkun/dev/godev/go-gerrit/src/runtime/panic.go:1121 +0x54
runtime.noSignalStack(0x10)
	/Users/changkun/dev/godev/go-gerrit/src/runtime/signal_unix.go:895 +0x78
runtime.adjustSignalStack(0x100000010, 0x100ece2c0, 0x130044888, 0x0)
	/Users/changkun/dev/godev/go-gerrit/src/runtime/signal_unix.go:486 +0x258
runtime.sigtrampgo(0x10, 0x1300449d0, 0x130044a38)
	/Users/changkun/dev/godev/go-gerrit/src/runtime/signal_unix.go:438 +0x15c
runtime: unexpected return pc for runtime.sigtramp called from 0x1f1189c18
stack: frame={sp:0x1300448d0, fp:0x1300449a0} stack=[0x13003c7e8,0x130044be8)
00000001300447d0:  0000000000000020  0000000130044848 
00000001300447e0:  0000000100d74fdc <runtime.sigtrampgo+348>  0000000000000010 
00000001300447f0:  0000000130044818  0000000130044848 
0000000130044800:  0000000130044858  0000000000000000 
0000000130044810:  0000000000000000  0000000000000000 
0000000130044820:  0000000000000000  0000000000000004 
0000000130044830:  0000000000000000  0000000130044848 
0000000130044840:  0000000100d74fb0 <runtime.sigtrampgo+304>  00000001300448c8 
0000000130044850:  0000000100d908f8 <runtime.sigtramp+136>  0000000100000010 
0000000130044860:  0000000100ece2c0  0000000130044888 
0000000130044870:  0000000000000000  0000000000000000 
0000000130044880:  0000000000000000  0000000000000000 
0000000130044890:  0000000000000000  0000000000000000 
00000001300448a0:  0000000000000000  0000000000000000 
00000001300448b0:  0000000130000300  00000001300449d0 
00000001300448c0:  0000000130044a38  00000001300449c0 
00000001300448d0: <00000001f1189c18  0000000000000010 
00000001300448e0:  00000001300449d0  0000000130044a38 
00000001300448f0:  9da526e2cfa9ab7e  0000000130044a38 
0000000130044900:  0000000203721000  0000000100eedc94 
0000000130044910:  0000000100eedc95  0000000100ecdc10 
0000000130044920:  0000000000000018  0000000100eb7fb8 
0000000130044930:  0000000000001690  0000000130000300 
0000000130044940:  00000001300448c8  0000000000000000 
0000000130044950:  0000000000000000  0000000000000000 
0000000130044960:  0000000000000000  0000000000000000 
0000000130044970:  0000000000000000  0000000000000000 
0000000130044980:  0000000000000000  0000000000000000 
0000000130044990:  0000000000000000  0000000000000000 
00000001300449a0: >0000000100eedc94  0000000000000003 
00000001300449b0:  000000000000007d  0000000000000030 
00000001300449c0:  0000000130044e18  e9067f8100d7d3d4 
00000001300449d0:  0000000000000010  0000000000000000 
00000001300449e0:  0000000000000000  0000000100d7d72c <runtime.step+44> 
00000001300449f0:  0000000000000000  0000000000000000 
0000000130044a00:  0000000000000000  0000000000000000 
0000000130044a10:  0000000000000000  0000000000000000 
0000000130044a20:  0000000000000000  0000000000000000 
0000000130044a30:  0000000000000000  0000000000000000 
0000000130044a40:  00000001300449d0  0000000000000000 
0000000130044a50:  0000000000000000  0000000000000000 
0000000130044a60:  0000000000000330  0000000130044a70 
0000000130044a70:  0000000100e70565  0000000092000007 
0000000130044a80:  0000000000000001  0000000000012f3b 
0000000130044a90:  0000000100e70565  0000000000000000 
runtime.sigtramp(0x3, 0x7d, 0x30, 0x130044e18, 0xe9067f8100d7d3d4, 0x10, 0x0, 0x0, 0x100d7d72c, 0x0, ...)
	/Users/changkun/dev/godev/go-gerrit/src/runtime/sys_darwin_arm64.s:238 +0x88

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
	/Users/changkun/dev/godev/go-gerrit/src/runtime/asm_arm64.s:1136 +0x4 fp=0x13005ffe0 sp=0x13005ffe0 pc=0x100d8fe04

goroutine 1 [running, locked to thread]:
	goroutine running on other thread; stack unavailable

@andydotxyz
Copy link
Contributor Author

@andydotxyz andydotxyz commented Aug 25, 2021

Oh you are my hero @changkun that patch fixes it :)

@bcmills
Copy link
Member

@bcmills bcmills commented Aug 25, 2021

The combination of iOS and sigaltstack reminds me of #35851. Is that issue related?

@changkun
Copy link
Contributor

@changkun changkun commented Aug 25, 2021

@bcmills I tested CL 344969 for an iOS 15 beta 6 real iPhone device, iOS 13/14/15 simulators, and the issue reported in #35851 did not occur. Would you mind give a small help and trigger a trybot run on CL344969?

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 30, 2021

sigaltstack is only supported on iOS 14 and later. I'm not sure what is the minimum supported iOS version we have. Per #35851 (comment) maybe we still support iOS 13?

Do you know why it crashes without sigaltstack? The runtime is supposed to work on iOS without using sigaltstack. It should switch to the signal stack manually upon entering the signal handler (in runtime.sigtramp).

cc @eliasnaur

@changkun
Copy link
Contributor

@changkun changkun commented Aug 30, 2021

sigaltstack is only supported on iOS 14 and later.

I am not sure if this is true. Test running on iOS 13 suggest no issue as commented above.

The runtime is supposed to work on iOS without using sigaltstack. It should switch to the signal stack manually upon entering the signal handler (in runtime.sigtramp).

As previously posted stack trace, the runtime triggers a panic: fatal error: non-Go code disabled sigaltstack

The previous commit in 1.16 indeed does not change ios/arm64 but the panic message seems to suggest somewhere else in the runtime disabled sigaltstack for non-Go code.

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 30, 2021

The error message reads "non-Go code disabled sigaltstack", which means the non-Go code itself disables sigaltstack, not the Go runtime disables it for the non-Go code.

It is true that the Go runtime should not expect sigaltstack being used on iOS, and it is okay that (Go code or non-Go code) disables sigaltstack. But the question is why we get there. What is supposed to happen is that runtime.sigtramp manually switches to the gsignal stack and runtime.adjustSignalStack returns early without getting to the throw later. Why this does not happen?

How is your iOS app built? Does it build with GOOS=ios?

@changkun
Copy link
Contributor

@changkun changkun commented Aug 30, 2021

How is your iOS app built? Does it build with GOOS=ios?

Of course, it follows the instruction from Go mobile's wiki page:

gomobile build -v -target=ios -bundleid design.golang.gclip-gui.app

which is correctly handled here: https://cs.opensource.google/go/x/mobile/+/master:cmd/gomobile/build.go;l=299

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 30, 2021

That line only sets the "ios" build tag, but not GOOS=ios. This does not enable the GOOS_ios macro in the assembly code. It should set GOOS=ios environment variable. As Go 1.15 is no longer supported we can probably do it unconditionally now.

cc @dmitshur

@changkun
Copy link
Contributor

@changkun changkun commented Aug 30, 2021

That line only sets the "ios" build tag, but not GOOS=ios. This does not enable the GOOS_ios macro in the assembly code.

Not sure if I understand every detail, but if the GOOS_ios macro is not enabled, shouldn't it do exactly what CL344969 (removes all GOOS_ios conditions) is trying to do?

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 30, 2021

Yes, that CL does fix the issue by removing the uses of the macros. But I think we still want to set GOOS=ios in gomobile. There may be other uses of the macro, and we may use it in other places in the future. The macro should just work. Removing the current uses only works around the problem, not fixing it.

@changkun
Copy link
Contributor

@changkun changkun commented Aug 30, 2021

I am still do not quite follow the theory here. The app fails after CL 256917, which adds GOOS_ios macro to assembly.

If GOOS is not set to ios, but wrongly set to darwin by gomobile, then the GOOS_ios condition is not executed. However, not executing the GOOS_ios condition is exactly what CL 344969 did (remove all GOOS_ios conditions, hence code never gets executed). This leads to a contradiction against the theory of GOOS. How does that CL a workaround?

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 30, 2021

The point is that the macro should just work. One should be able to use the macro and the program should do the right thing. Removing the uses fixes the immediate issue, but there is still something broken, namely the macro doesn't work. It is like, if I break the "go" statement in the compiler and tell you just not using the "go" statement.

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 30, 2021

Change https://golang.org/cl/346150 mentions this issue: x/mobile: use GOOS=ios for iOS builds in gomobile

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Aug 30, 2021

If we decide to drop iOS 13 support, we can just go ahead with your CL. But besides that, we should also make gomobile do the right thing.

@changkun
Copy link
Contributor

@changkun changkun commented Aug 30, 2021

I just sent CL 346150 that does the fix for GOOS in gomobile.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 1, 2021

Change https://golang.org/cl/346390 mentions this issue: cmd/gomobile: enable bitcode unconditionally

gopherbot pushed a commit to golang/mobile that referenced this issue Sep 1, 2021
This change permits gomobile to build iOS applications by properly
set GOOS=ios in the build process. The change is locally tested on
darwin/arm64, and golang.org/x/mobile/example/basic can be build
using the following commands:

gomobile build -target=android -o=basic.apk \
golang.org/x/mobile/example/basic

gomobile build -target=ios -bundleid=org.golang.gomobiletest \
-o=basic.app golang.org/x/mobile/example/basic

The built binaries are also tested on iOS 15 beta7 and Android 12 API31.

Updates golang/go#47952
Fixes golang/go#47238

Change-Id: Ibf40a77933ac957640c78d0dbc1af043477e4b3a
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/346150
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopherbot pushed a commit to golang/mobile that referenced this issue Sep 1, 2021
As discussed in CL 346150, conditional bitcode build flag was introduced
in CL 214899, for Go >= 1.14 but not Go 1.13.

Since we have dropped the support for 1.13, all bitcode conditions
can be removed.

Hence this CL removes it.

Updates golang/go#47952

Change-Id: I0436cad8d5ab5675b647e25e7dfa85af85996a7e
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/346390
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants