I have an Go application compiled for Android with gomobile. When a panic happens, the runtime prints a traceback and quits. However, when this traceback is long enough, the application freezes and never quits.
cc @eliasnaur, I know you don't maintain it anymore but it would be nice to know if the now built-in support in Go itself would enable to remove this bit in gomobile, or there were some other reason for it to exist?
changed the title
mobile: when a panic happens, a long enough traceback deadlocks the runtime on AndroidNov 14, 2019
Another idea would be to implement a buffered writer and only replace os.Stdout/Stderr. That won't redirect all stdout/stderr logging, but Go code would be fine, and stderr wouldn't be duped, so the dump would work.
Wonder if it's possible to let the gomobile directly send all logs to logd using the code similar to runtime/write_err_android.go. More desirably, would be nice if it allows users to turn it on and off - I found logging from some libraries is too chatty for mobile application use cases.
As stderr may be written while the world is frozen (e.g. the runtime
dumping the traceback of a panic), the redirection of stdout and stderr
to Android's logcat cannot be done in Go but in C.
This implementation spawns a detached thread which will wait for stdout
or stderr to be readable, and when so, read one line at a time and
write it to Android's logcat.