It would be nice if after a crash, a user could use both our own hs_err_pid log and Apple's crash reporter log. As it is, Apple crash report logs incorrect state of our own process handler, not the original crash:

Our hs_err_pid reports correctly:

V [libjvm.dylib+0xc39db1] VMError::controlled_crash(int)+0x3cf
V [libjvm.dylib+0x6038fc] JNI_CreateJavaVM+0x568
C [libjli.dylib+0x3fc7] JavaMain+0x10b
C [libjli.dylib+0x6b5d] ThreadJavaMain+0x9
C [libsystem_pthread.dylib+0x5e65] _pthread_start+0x94
C [libsystem_pthread.dylib+0x183b] thread_start+0xf

But Apple's crash reporter logs incorrectly:

Thread 2 Crashed:
0 libsystem_kernel.dylib 0x00007fff70d067fa __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff70dc3bc1 pthread_kill + 432
2 libsystem_c.dylib 0x00007fff70c8da1c abort + 120
3 libjvm.dylib 0x0000000109ad5737 os::abort(bool, void*, void const*) (.cold.1) + 125
4 libjvm.dylib 0x000000010975b611 os::abort(bool, void*, void const*) + 33 (os_bsd.cpp:1070)
5 libjvm.dylib 0x0000000109a3b0cd VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) + 3057 (vmError.cpp:1624)
6 libjvm.dylib 0x0000000109a3a4b8 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) + 148 (vmError.cpp:1291)
7 libjvm.dylib 0x0000000109a3b1a1 VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*) + 33 (vmError.cpp:1298)
8 libjvm.dylib 0x000000010975fda1 JVM_handle_bsd_signal + 787 (os_bsd_x86.cpp:791)
9 libjvm.dylib 0x000000010975d0cc signalHandler(int, __siginfo*, void*) + 89 (os_bsd.cpp:2631)
10 libsystem_platform.dylib 0x00007fff70db842d _sigtramp + 29
11 ??? 0x0000000000000080 0 + 128
12 libjvm.dylib 0x00000001094038fc JNI_CreateJavaVM + 1384 (jni.cpp:3935)
13 libjli.dylib 0x0000000107cabfc7 JavaMain + 267 (java.c:417)
14 libjli.dylib 0x0000000107caeb5d ThreadJavaMain + 9 (java_md_macosx.m:716)
15 libsystem_pthread.dylib 0x00007fff70dc3e65 _pthread_start + 148
16 libsystem_pthread.dylib 0x00007fff70dbf83b thread_start + 15

I.e. it reports our signal handler, which is a pity because otherwise it provides a wide range of info, which our own handler doesn't, such as back trace of all native threads (and line numbers to files instead of offsets, and list of binary images sorted by their addresses, and user friendly OS X version), which is super useful for tracking multithreaded issues.

Also, it would be nice if our hs_err_pid log could include a link to Apple's own crash log.

Just noticed: if "-XX:-CreateCoredumpOnCrash" was used, then we would exit the process via exit() API, so Apple's CrashReporter would see that as clean exit and wouldn't generate its own crash log at all.