[native] Let Android know what is our reason to abort()

[grendello]

Android C API includes a function which allows the caller to set a
text message indicating the reason why the application is aborting
its execution using the abort(3) function, since the call doesn't
accept any parameters. The message is then used in the native stack
trace (as well as in the application tombstone), which may be helpful
for us when reading crash reports which contain just the stack trace
and no context information.

Given the following code:

 Helpers::abort_application (LOG_ASSEMBLY, "Testing abort stuff");

We will see the following logged in logcat:

 F monodroid-assembly: Testing abort stuff
 F monodroid-assembly: Abort at monodroid-glue.cc:825:2 ('void xamarin::android::internal::MonodroidRuntime::init_android_runtime(JNIEnv *, jclass, jobject)')

 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 8803 (XAPerfTest.net9), pid 8803 (XAPerfTest.net9)
 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstoneProto
 I tombstoned: received crash request for pid 8803
 I crash_dump64: performing dump of process 8803 (target tid = 8803)
 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
 F DEBUG   : Build fingerprint: 'google/raven/raven:14/AP2A.240805.005.F1/12043167:user/release-keys'
 F DEBUG   : Revision: 'MP1.0'
 F DEBUG   : ABI: 'arm64'
 F DEBUG   : Timestamp: 2024-09-24 12:00:57.245408791+0200
 F DEBUG   : Process uptime: 1s
 F DEBUG   : Cmdline: com.xamarin.XAPerfTest.net9
 F DEBUG   : pid: 8803, tid: 8803, name: XAPerfTest.net9  >>> com.xamarin.XAPerfTest.net9 <<<
 F DEBUG   : uid: 10456
 F DEBUG   : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
 F DEBUG 👉: Abort message: 'Testing abort stuff'
 F DEBUG   :     x0  0000000000000000  x1  0000000000002263  x2  0000000000000006  x3  0000007fc7ed5530
 F DEBUG   :     x4  3139343137396262  x5  3139343137396262  x6  3139343137396262  x7  7f7f7f7f7f7f7f7f
 F DEBUG   :     x8  00000000000000f0  x9  000000721c528350  x10 0000000000000001  x11 000000721c579170
 F DEBUG   :     x12 0000007fc7ed3e50  x13 0000000000000088  x14 0000007fc7ed5068  x15 000000057ae2d47e
 F DEBUG   :     x16 000000721c5dffd0  x17 000000721c5cb560  x18 0000007230490000  x19 0000000000002263
 F DEBUG   :     x20 0000000000002263  x21 00000000ffffffff  x22 0000006f69e1d7d6  x23 0000007fc7ed58a4
 F DEBUG   :     x24 0000007fc7ed58c8  x25 0000000000000000  x26 0000000000000000  x27 b400007218a0a060
 F DEBUG   :     x28 0000000000000000  x29 0000007fc7ed55b0
 F DEBUG   :     lr  000000721c5628b8  sp  0000007fc7ed5510  pc  000000721c5628e4  pst 0000000000001000

(the rest of stack trace is omitted for brevity)

We log the indicated message before calling abort(), but it also
appears on the Abort message: line in the stack trace.

Additionally, don't log the full path to the source file containing the
abort call, a file name is just enough.

[jonpryor]

Do we not want sloc in this message either?

It feels like what we might want is C#-esque ${message}{(log_location ? $"\nabort at {sloc}" : "")}, which would allow the location to be part of the abort message.

Question: can the message contain a newline? Does that work and what does the logcat output look like?

[grendello]

Alas, it appears the maximum length of the message is 120 characters, so we can't really stuff the location info in there :(

[jonpryor]

If the maximum assertion message length is 120 characters, doesn't this message -- at 305 characters -- vastly exceed it?

[grendello]

It does, but the message is logged separately, too, so we'll get the full message in logcat.

[grendello]

This particular message might no longer be needed, since we don't support API10 anymore.

[jonpryor]

Because there is a maximum assert message length of 120 characters, every call to Helpers::abort_application() must be reviewed to ensure that the most important parts of the message come first. This may involve leaving the preceding log_fatal() calls, as their message length is much longer, and having a "most important parts" message within the assert message.

[grendello]

Because there is a maximum assert message length of 120 characters, every call to Helpers::abort_application() must be reviewed to ensure that the most important parts of the message come first. This may involve leaving the preceding log_fatal() calls, as their message length is much longer, and having a "most important parts" message within the assert message.

I agree that the most important info must come first, but there's no reason to leave the preceding log_fatal calls since the message is logged in full in Helpers::abort_application