x/mobile: iOS apps crash on launch since 1.16 #47952
Comments
|
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 |
|
Update: I added a |
|
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 A single file reproducer (using gomobile): https://github.com/golang-design/clipboard/blob/main/cmd/gclip-gui/main.go |
|
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. |
This comment has been minimized.
This comment has been minimized.
|
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. |
|
After a bisect on the tree with the above example, the issue was introduced in 28e549dec3 . |
toothrot
added
the
NeedsInvestigation
|
Change https://golang.org/cl/344969 mentions this issue: |
|
I just sent a CL that should fix the problem. This is a crash log (after 28e549dec3): |
|
Oh you are my hero @changkun that patch fixes it :) |
|
The combination of iOS and |
|
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 |
I am not sure if this is true. Test running on iOS 13 suggest no issue as commented above.
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. |
|
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? |
Of course, it follows the instruction from Go mobile's wiki page: which is correctly handled here: https://cs.opensource.google/go/x/mobile/+/master:cmd/gomobile/build.go;l=299 |
|
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 |
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? |
|
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. |
|
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? |
|
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. |
|
Change https://golang.org/cl/346150 mentions this issue: |
|
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. |
|
I just sent CL 346150 that does the fix for GOOS in gomobile. |
|
Change https://golang.org/cl/346390 mentions this issue: |
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>
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>
What version of Go are you using (
go version)?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
The text was updated successfully, but these errors were encountered: