Mono app crashing with SIGABRT and SIGILL

[deepgoyal25]

Steps to Reproduce

We are not able to root cause the issue and therefore not able to reproduce.
We have the uncaught exception handler in our code which is also not getting called in these crashes.

Current Behavior

App is crashing

Expected Behavior

App should not crash. If it crashes, our uncaught exception handler should get called

On which platforms did you notice this

macOS

Version Used:
Macosx 10.12, 10.13 and 10.14
Mono 5.12

Stacktrace

From Diagnostic logs, we see the stack trace attached in AppCrash_SIGABRT.txt and AppCrash_SIGILL.txt
AppCrash_SIGILL.txt

AppCrash_SIGABRT.txt

[lambdageek]

Thanks for reporting the issue, @deepgoyal25.

1. The SIGABRT crash looks like it's happening in libosxfuse - does your app use a managed binding for FUSE, perhaps? Perhaps it's being passed some bad arguments.
2. the SIGILL crash looks interesting. A thread info key destructor is running and asserting. (That function is pretty assertion-heavy, so I can't tell which assertion is failing). @deepgoyal25 is this crash happening when the app is shutting down?

This looks like a relevant bit from the SIGILL crash report

Thread 7 Crashed:: tid_c903
0   libsystem_c.dylib             	0x00007fff5363326e __abort + 177
1   libsystem_c.dylib             	0x00007fff536331bd abort + 142
2   com.MyApp     	0x0000000102960d3b mono_handle_native_crash + 603
3   com.MyApp     	0x000000010297047e mono_sigill_signal_handler + 46
4   libsystem_platform.dylib      	0x00007fff53895f5a _sigtramp + 26
5   ???                           	0x0000000102c7d170 0 + 4341617008
6   libsystem_c.dylib             	0x00007fff536331bd abort + 142
7   com.MyApp     	0x00000001028668b0 log_callback(char const*, char const*, char const*, int, void*) + 64
8   com.MyApp     	0x0000000102b21573 monoeg_g_logv + 83
9   com.MyApp     	0x0000000102b2178f monoeg_assertion_message + 143
10  com.MyApp     	0x0000000102a8bb81 thread_detach + 129
11  com.MyApp     	0x0000000102b14d48 unregister_thread + 184
12  com.MyApp     	0x0000000102b15340 thread_info_key_dtor + 32
13  libsystem_pthread.dylib       	0x00007fff538a1163 _pthread_tsd_cleanup + 463
14  libsystem_pthread.dylib       	0x00007fff538a0ee9 _pthread_exit + 79
15  libsystem_pthread.dylib       	0x00007fff5389f66c _pthread_body + 351
16  libsystem_pthread.dylib       	0x00007fff5389f50d _pthread_start + 377
17  libsystem_pthread.dylib       	0x00007fff5389ebf9 thread_start + 13

[deepgoyal25]

1. The SIGABRT crash looks like it's happening in libosxfuse - does your app use a managed binding for FUSE, perhaps? Perhaps it's being passed some bad arguments.
   [Deep] - Yes, we have a managed binding for FUSE. Can you tell how were you able to infer that crash is happening because of an incoming fuse call? Also, is the crash expected in this case?
2. the SIGILL crash looks interesting. A thread info key destructor is running and asserting. (That function is pretty assertion-heavy, so I can't tell which assertion is failing). @deepgoyal25 is this crash happening when the app is shutting down?
   [Deep] - I checked the logs of the application and yes, it looks like it is happening when app is shutting down. Can you please tell if it is safe to ignore these since app is anyways shutting down?

In general, can you tell if there is a way to handle these crashes in our app? If not, how can we make our app know that app is going to crash. We have planted uncaught exception handler but that code is getting called when app crashes.

[deepgoyal25]

@lambdageek - I dig into more details about SIGABRT and were able to see that some code path in fuse causing the abort to be called

About SIGILL, I looked at the logs of other customers and found that it is not always happening on the app shutdown path. Can you please more insights on how to resolve this issue or how to dig more into the issue