cmd/ebitenmobile: better way to handle panics instead of converting errors on mobiles

[hajimehoshi]

See #800

Now panics are converted to errors, but this is hacky. We should find a better way to handle panic to report to Crashlytics.

https://firebase.google.com/docs/crashlytics/ndk-reports

[hajimehoshi]

NDK reports did not work well...

http://blog.httrack.com/blog/2013/08/23/catching-posix-signals-on-android/ sounds the last resort?

[hajimehoshi]

Finally succeeded to get the report!

(I tried the crashing version and tried the non-crashing version next, that reported to Crashlytics the last crash.)

The symbols are hidden. I'd need to upload this.

[hajimehoshi]

Hmm, I wasn't able to find a way to upload symbols in a shared library.

Another way (using CoffeeCatch) didn't work due to compile errors (macro conflicts?). Even they were fixed, there seems a lot of reported issues.

EDIT: xroche/coffeecatch#29 seems critical :-/

[hajimehoshi]

https://chromium.googlesource.com/breakpad/breakpad/

Another candidate

[hajimehoshi]

This issue is not easy to solve.

[hajimehoshi]

https://stackoverflow.com/questions/53370341/how-to-get-the-stack-trace-of-golang-in-the-crashlytics

[hajimehoshi]

• When panics happens, there are no guarantees about the state of Go runtime.
• Usually the panic message is written to write1. There is no obvious way to get the output without modifying the runtime.

So, my vague idea is to use a modified runtime when compiling apps with ebitenmobile. I'm not sure it'd be possible.

[hajimehoshi]

So, my vague idea is to use a modified runtime when compiling apps with ebitenmobile. I'm not sure it'd be possible.

It's possible with -overlay.