Open DmitryTupikin opened 7 years ago
/cc @rakyll @hyangah @crawshaw
Guys, have you had a chance to look at that issue? It's really important thing. Google Play Dev Support team uses exactly the same device to verify app behaviour on Android TV. That means every developer who use gomobile in his app and want to support Android TV devices will fail with Google Play publishing procedure.
I have a Nexus Player if any of the people in CAM want to investigate this in-person (@cherrymui ?)
(Sorry about the brief assignment, grr GitHub mobile UI)
@DmitryTupikin We think the Go library tried to write to stderr before this crash occurred. Do you see anything in the logcat output that starts with "runtime/cgo:"? I don't know how to get at stderr on Android.
Rebuilding with roughly the same compiler, the PC of the abort is in inittls
in gcc_android_386.c
, That function calls abort()
in two different places, both times it prints to stderr before the crash.
/cc @hyangah Hana, you have TODOs in this function about "fix this" and "check 0xb0 works with API23+" :)
@quentinmit Unfortunately I can't see stderr in standard Logcat output because it's redirected into /dev/null by OS by default. It might be redirected by changing prop files of OS, but it works only on rooted devices if I'm right. My player has no ROOT.
Guys, do you have any updates on that?
@hyangah can you help us with the issue please? We're waiting for 3 months. This is not a minor problem, and as I said before, it affects all the Android developers who use go for android tv apps.
You can see if this issue allows you to rewire the standard error file descriptor to some other file.
The principle is that by calling os.Stderr.Close()
and following it with an os.Create("/path/to/new/logfile.txt")
the panic trace will print to the log file instead of wherever it was going.
I currently have no way to access android devices to reproduce the issue.
The code @quentinmit mentioned seems to be highly likely the source of the crash. In order to verify it, I think we need to 1) use gdb, or 2) use ndk c logging api instead of stderr, or 3) find another way to change stderr redirection. The code runs before Go runtime is initialized, so go-based trick to redirect the log message will not work most likely). Is it possible to do one of the approaches to get more info?
I'd like to fix this but don't have a device to reproduce this on. @DmitryTupikin from the crash it seems the 'x86' ABI is in use. Is there a reason you're not using x86_64? If you like, use gomobile bind -target=android/amd64 ...
to bind only for android/amd64.
@quentinmit, note that gomobile apps works fine on my Pixel device, which is api level 26 so I think the comment about 23+ is stale.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8.3 darwin/amd64
What operating system and processor architecture are you using (
go env
)?OSX Sierra 10.12.5 GOARCH="amd64" GOOS="darwin"
What did you do?
gomobile bind -target=android golang.org/x/mobile/example/bind/hello
hello.Hello.greetings("Test");
What did you expect to see?
Everything works OK.
What did you see instead?
App is built and run, but it crashes when golang call is happened. There's a logcat output:
06-27 13:54:27.849 10901-10930/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 10930 (upikin.mygotest)
[ 06-27 13:54:27.849 160: 160 W/ ] debuggerd: handling request: pid=10901 uid=10071 gid=10071 tid=10930 06-27 13:54:27.883 10931-10931/? A/DEBUG: 06-27 13:54:27.883 10931-10931/? A/DEBUG: Build fingerprint: 'google/fugu/fugu:7.1.2/N2G47X/4026974:user/release-keys' 06-27 13:54:27.883 10931-10931/? A/DEBUG: Revision: '0' 06-27 13:54:27.883 10931-10931/? A/DEBUG: ABI: 'x86' 06-27 13:54:27.883 10931-10931/? A/DEBUG: pid: 10901, tid: 10930, name: upikin.mygotest >>> com.example.dtupikin.mygotest <<< 06-27 13:54:27.883 10931-10931/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 06-27 13:54:27.883 10931-10931/? A/DEBUG: eax 00000000 ebx 00002a95 ecx 00002ab2 edx 00000006 06-27 13:54:27.883 10931-10931/? A/DEBUG: esi d0c47978 edi d0c47920 06-27 13:54:27.883 10931-10931/? A/DEBUG: xcs 00000023 xds 0000002b xes 0000002b xfs 0000006b xss 0000002b 06-27 13:54:27.883 10931-10931/? A/DEBUG: eip ffffe430 ebp d0c474e8 esp d0c4748c flags 00000296 06-27 13:54:27.886 10931-10931/? A/DEBUG: backtrace: 06-27 13:54:27.886 10931-10931/? A/DEBUG: #00 pc ffffe430 [vdso:ffffe000] (__kernel_vsyscall+16) 06-27 13:54:27.887 10931-10931/? A/DEBUG: #01 pc 000893dc /system/lib/libc.so (tgkill+28) 06-27 13:54:27.887 10931-10931/? A/DEBUG: #02 pc 00084c35 /system/lib/libc.so (pthread_kill+85) 06-27 13:54:27.887 10931-10931/? A/DEBUG: #03 pc 00036c2a /system/lib/libc.so (raise+42) 06-27 13:54:27.887 10931-10931/? A/DEBUG: #04 pc 0002e186 /system/lib/libc.so (abort+86) 06-27 13:54:27.887 10931-10931/? A/DEBUG: #05 pc 000a42e3 /data/app/com.example.dtupikin.mygotest-2/lib/x86/libgojni.so
I do my tests on Asus Nexus Player (Android TV 7.1.2). The issue doesn't happen on Android TV emulator (versions 5,6,7)
Tried to build aar on another PC (Windows 10 x64). The same crash happens.