Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

check faulting address before throwing NRE on implicit null checking #1

Open
lewurm opened this issue May 12, 2018 · 0 comments
Open

Comments

@lewurm
Copy link
Owner

lewurm commented May 12, 2018

if it's a weird looking address, maybe replace it with a ExecutionEngineException? or just let it native crash?

this could hep with identifying runtime crashes that are masked by NREs.

lewurm pushed a commit that referenced this issue May 17, 2018
* [btls] Do not give gcc flags to msvc.

* [btls] #include "btls-foo.h" instead of #include <btls-foo.h> to work
with existing build system, on Windows, with out-of-tree build.
Not sure which factor does not like <> but "" should be ok.

* [blts] MONO_API is not used consistently and therefore errors on Windows.
1. Make it be nothing.
1b. Use a .def file if there are actual exports.
Really, .def files are a good idea.

 or

2. Use it consistently.

This does #1.
lewurm pushed a commit that referenced this issue Nov 1, 2018
We were previously only setting it from the icall. The icall was
therefore fine, while invocations associated with actual dumps
caused crashes like this:

```

thread mono#10, name = 'Thread Pool Worker'
    frame #0: 0x00007fff978dac22 libsystem_kernel.dylib`__psynch_mutexwait + 10
    frame #1: 0x00007fff979c5dfa libsystem_pthread.dylib`_pthread_mutex_lock_wait + 100
    frame #2: 0x00007fff979c3519 libsystem_pthread.dylib`_pthread_mutex_lock_slow + 285
    frame mono#3: 0x0000000108e0d4a9 mono`mono_loader_lock + 73
    frame mono#4: 0x0000000108dc9106 mono`mono_class_create_from_typedef + 182
    frame mono#5: 0x0000000108dc1f2c mono`mono_class_get_checked + 92
    frame mono#6: 0x0000000108e21da2 mono`mono_metadata_parse_type_internal + 1378
    frame mono#7: 0x0000000108e25e11 mono`mono_metadata_parse_mh_full + 1233
    frame mono#8: 0x0000000108ca4f79 mono`mono_debug_add_aot_method + 121
    frame mono#9: 0x0000000108cc6b1e mono`decode_exception_debug_info + 5918
    frame mono#10: 0x0000000108cc5047 mono`mono_aot_find_jit_info + 1367
    frame mono#11: 0x0000000108e082cc mono`mono_jit_info_table_find_internal + 204
    frame mono#12: 0x0000000108cdb035 mono`mini_jit_info_table_find_ext + 69
    frame mono#13: 0x0000000108cdad5c mono`mono_find_jit_info_ext + 124
    frame mono#14: 0x0000000108cdc3a5 mono`unwinder_unwind_frame + 229
    frame mono#15: 0x0000000108cdbade mono`mono_walk_stack_full + 798
    frame mono#16: 0x0000000108cda1a4 mono`mono_summarize_managed_stack + 100
    frame mono#17: 0x0000000108e6dc03 mono`mono_threads_summarize_execute + 1347
    frame mono#18: 0x0000000108e6df88 mono`mono_threads_summarize + 360

```
lewurm pushed a commit that referenced this issue Nov 2, 2018
We were previously only setting it from the icall. The icall was
therefore fine, while invocations associated with actual dumps
caused crashes like this:

```

thread mono#10, name = 'Thread Pool Worker'
    frame #0: 0x00007fff978dac22 libsystem_kernel.dylib`__psynch_mutexwait + 10
    frame #1: 0x00007fff979c5dfa libsystem_pthread.dylib`_pthread_mutex_lock_wait + 100
    frame #2: 0x00007fff979c3519 libsystem_pthread.dylib`_pthread_mutex_lock_slow + 285
    frame mono#3: 0x0000000108e0d4a9 mono`mono_loader_lock + 73
    frame mono#4: 0x0000000108dc9106 mono`mono_class_create_from_typedef + 182
    frame mono#5: 0x0000000108dc1f2c mono`mono_class_get_checked + 92
    frame mono#6: 0x0000000108e21da2 mono`mono_metadata_parse_type_internal + 1378
    frame mono#7: 0x0000000108e25e11 mono`mono_metadata_parse_mh_full + 1233
    frame mono#8: 0x0000000108ca4f79 mono`mono_debug_add_aot_method + 121
    frame mono#9: 0x0000000108cc6b1e mono`decode_exception_debug_info + 5918
    frame mono#10: 0x0000000108cc5047 mono`mono_aot_find_jit_info + 1367
    frame mono#11: 0x0000000108e082cc mono`mono_jit_info_table_find_internal + 204
    frame mono#12: 0x0000000108cdb035 mono`mini_jit_info_table_find_ext + 69
    frame mono#13: 0x0000000108cdad5c mono`mono_find_jit_info_ext + 124
    frame mono#14: 0x0000000108cdc3a5 mono`unwinder_unwind_frame + 229
    frame mono#15: 0x0000000108cdbade mono`mono_walk_stack_full + 798
    frame mono#16: 0x0000000108cda1a4 mono`mono_summarize_managed_stack + 100
    frame mono#17: 0x0000000108e6dc03 mono`mono_threads_summarize_execute + 1347
    frame mono#18: 0x0000000108e6df88 mono`mono_threads_summarize + 360

```
lewurm pushed a commit that referenced this issue Nov 8, 2018
We were previously only setting it from the icall. The icall was
therefore fine, while invocations associated with actual dumps
caused crashes like this:

```

thread mono#10, name = 'Thread Pool Worker'
    frame #0: 0x00007fff978dac22 libsystem_kernel.dylib`__psynch_mutexwait + 10
    frame #1: 0x00007fff979c5dfa libsystem_pthread.dylib`_pthread_mutex_lock_wait + 100
    frame #2: 0x00007fff979c3519 libsystem_pthread.dylib`_pthread_mutex_lock_slow + 285
    frame mono#3: 0x0000000108e0d4a9 mono`mono_loader_lock + 73
    frame mono#4: 0x0000000108dc9106 mono`mono_class_create_from_typedef + 182
    frame mono#5: 0x0000000108dc1f2c mono`mono_class_get_checked + 92
    frame mono#6: 0x0000000108e21da2 mono`mono_metadata_parse_type_internal + 1378
    frame mono#7: 0x0000000108e25e11 mono`mono_metadata_parse_mh_full + 1233
    frame mono#8: 0x0000000108ca4f79 mono`mono_debug_add_aot_method + 121
    frame mono#9: 0x0000000108cc6b1e mono`decode_exception_debug_info + 5918
    frame mono#10: 0x0000000108cc5047 mono`mono_aot_find_jit_info + 1367
    frame mono#11: 0x0000000108e082cc mono`mono_jit_info_table_find_internal + 204
    frame mono#12: 0x0000000108cdb035 mono`mini_jit_info_table_find_ext + 69
    frame mono#13: 0x0000000108cdad5c mono`mono_find_jit_info_ext + 124
    frame mono#14: 0x0000000108cdc3a5 mono`unwinder_unwind_frame + 229
    frame mono#15: 0x0000000108cdbade mono`mono_walk_stack_full + 798
    frame mono#16: 0x0000000108cda1a4 mono`mono_summarize_managed_stack + 100
    frame mono#17: 0x0000000108e6dc03 mono`mono_threads_summarize_execute + 1347
    frame mono#18: 0x0000000108e6df88 mono`mono_threads_summarize + 360

```
lewurm pushed a commit that referenced this issue Nov 8, 2018
We were previously only setting it from the icall. The icall was
therefore fine, while invocations associated with actual dumps
caused crashes like this:

```

thread mono#10, name = 'Thread Pool Worker'
    frame #0: 0x00007fff978dac22 libsystem_kernel.dylib`__psynch_mutexwait + 10
    frame #1: 0x00007fff979c5dfa libsystem_pthread.dylib`_pthread_mutex_lock_wait + 100
    frame #2: 0x00007fff979c3519 libsystem_pthread.dylib`_pthread_mutex_lock_slow + 285
    frame mono#3: 0x0000000108e0d4a9 mono`mono_loader_lock + 73
    frame mono#4: 0x0000000108dc9106 mono`mono_class_create_from_typedef + 182
    frame mono#5: 0x0000000108dc1f2c mono`mono_class_get_checked + 92
    frame mono#6: 0x0000000108e21da2 mono`mono_metadata_parse_type_internal + 1378
    frame mono#7: 0x0000000108e25e11 mono`mono_metadata_parse_mh_full + 1233
    frame mono#8: 0x0000000108ca4f79 mono`mono_debug_add_aot_method + 121
    frame mono#9: 0x0000000108cc6b1e mono`decode_exception_debug_info + 5918
    frame mono#10: 0x0000000108cc5047 mono`mono_aot_find_jit_info + 1367
    frame mono#11: 0x0000000108e082cc mono`mono_jit_info_table_find_internal + 204
    frame mono#12: 0x0000000108cdb035 mono`mini_jit_info_table_find_ext + 69
    frame mono#13: 0x0000000108cdad5c mono`mono_find_jit_info_ext + 124
    frame mono#14: 0x0000000108cdc3a5 mono`unwinder_unwind_frame + 229
    frame mono#15: 0x0000000108cdbade mono`mono_walk_stack_full + 798
    frame mono#16: 0x0000000108cda1a4 mono`mono_summarize_managed_stack + 100
    frame mono#17: 0x0000000108e6dc03 mono`mono_threads_summarize_execute + 1347
    frame mono#18: 0x0000000108e6df88 mono`mono_threads_summarize + 360

```
lewurm pushed a commit that referenced this issue Jan 23, 2019
* [runtime] Make infrastructure for merp tests

* [runtime] Fix dumping when crash happens without sigctx

* [runtime] Disable crashy (886/1000 runs) stacktrace walker

* [crash] Remove usage of allocating build/os info functions

* [crash] Remove often-crashing g_free on native crash path

* [crash] Add crash_reporter checked build

We add a checked build mode that asserts when mono mallocs inside of
the crash reporter. It makes risky allocations into assertions. It's
useful for automated testing because the double-abort often represents
itself as an indefinite hang. If it happens before the thread dumping
supervisor process is started, or after it ends, the crash reporter
hangs.

* [crash] Remove reliance on nested SIGABRT/double-fault (broken on OSX)

* [crash] Fix top-level handling of double faults/assertions

* [runtime] Make fatal unwinding errors return into handled error paths

* [crash] Change dumper logging for better info

* [runtime] Fix handling of segfault on sgen thread

Threads without domains that get segfaults will end up in
this handler. It's not safe to call this function with a NULL domain.

See crash below:

```
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x10eff40f8)
  * frame #0: 0x000000010e1510d9 mono-sgen`mono_threads_summarize_execute(ctx=0x0000000000000000, out=0x0000001000000000, hashes=0x0000100000100000, silent=4096, mem="", provided_size=2199023296512) at threads.c:6414
    frame #1: 0x000000010e152092 mono-sgen`mono_threads_summarize(ctx=0x000000010effda00, out=0x000000010effdba0, hashes=0x000000010effdb90, silent=0, signal_handler_controller=1, mem=0x0000000000000000, provided_size=0) at threads.c:6508
    frame #2: 0x000000010df7c69f mono-sgen`dump_native_stacktrace(signal="SIGSEGV", ctx=0x000000010effef48) at mini-posix.c:1026
    frame mono#3: 0x000000010df7c37f mono-sgen`mono_dump_native_crash_info(signal="SIGSEGV", ctx=0x000000010effef48, info=0x000000010effeee0) at mini-posix.c:1147
    frame mono#4: 0x000000010de720a9 mono-sgen`mono_handle_native_crash(signal="SIGSEGV", ctx=0x000000010effef48, info=0x000000010effeee0) at mini-exceptions.c:3227
    frame mono#5: 0x000000010dd6ac0d mono-sgen`mono_sigsegv_signal_handler_debug(_dummy=11, _info=0x000000010effeee0, context=0x000000010effef48, debug_fault_addr=0xffffffffffffffff) at mini-runtime.c:3574
    frame mono#6: 0x000000010dd6a8d3 mono-sgen`mono_sigsegv_signal_handler(_dummy=11, _info=0x000000010effeee0, context=0x000000010effef48) at mini-runtime.c:3612
    frame mono#7: 0x00007fff73dbdf5a libsystem_platform.dylib`_sigtramp + 26
    frame mono#8: 0x0000000110bb81c1
    frame mono#9: 0x000000011085ffe1
    frame mono#10: 0x000000010dd6d4f3 mono-sgen`mono_jit_runtime_invoke(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, exc=0x00007ffee1ea9f08, error=0x00007ffee1eaa250) at mini-runtime.c:3215
    frame mono#11: 0x000000010e11509d mono-sgen`do_runtime_invoke(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, exc=0x0000000000000000, error=0x00007ffee1eaa250) at object.c:2977
    frame mono#12: 0x000000010e10d961 mono-sgen`mono_runtime_invoke_checked(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, error=0x00007ffee1eaa250) at object.c:3145
    frame mono#13: 0x000000010e11aa58 mono-sgen`do_exec_main_checked(method=0x00007faae4f01fe8, args=0x000000010f0003e8, error=0x00007ffee1eaa250) at object.c:5042
    frame mono#14: 0x000000010e118803 mono-sgen`mono_runtime_exec_main_checked(method=0x00007faae4f01fe8, args=0x000000010f0003e8, error=0x00007ffee1eaa250) at object.c:5138
    frame mono#15: 0x000000010e118856 mono-sgen`mono_runtime_run_main_checked(method=0x00007faae4f01fe8, argc=2, argv=0x00007ffee1eaa760, error=0x00007ffee1eaa250) at object.c:4599
    frame mono#16: 0x000000010de1db2f mono-sgen`mono_jit_exec_internal(domain=0x00007faae4f00860, assembly=0x00007faae4c02ab0, argc=2, argv=0x00007ffee1eaa760) at driver.c:1298
    frame mono#17: 0x000000010de1d95d mono-sgen`mono_jit_exec(domain=0x00007faae4f00860, assembly=0x00007faae4c02ab0, argc=2, argv=0x00007ffee1eaa760) at driver.c:1257
    frame mono#18: 0x000000010de2257f mono-sgen`main_thread_handler(user_data=0x00007ffee1eaa6a0) at driver.c:1375
    frame mono#19: 0x000000010de20852 mono-sgen`mono_main(argc=3, argv=0x00007ffee1eaa758) at driver.c:2551
    frame mono#20: 0x000000010dd56d7e mono-sgen`mono_main_with_options(argc=3, argv=0x00007ffee1eaa758) at main.c:50
    frame mono#21: 0x000000010dd5638d mono-sgen`main(argc=3, argv=0x00007ffee1eaa758) at main.c:406
    frame mono#22: 0x00007fff73aaf015 libdyld.dylib`start + 1
    frame mono#23: 0x00007fff73aaf015 libdyld.dylib`start + 1
  thread #2, name = 'SGen worker'
    frame #0: 0x000000010e2afd77 mono-sgen`mono_get_hazardous_pointer(pp=0x0000000000000178, hp=0x000000010ef87618, hazard_index=0) at hazard-pointer.c:208
    frame #1: 0x000000010e0b28e1 mono-sgen`mono_jit_info_table_find_internal(domain=0x0000000000000000, addr=0x00007fff73bffa16, try_aot=1, allow_trampolines=1) at jit-info.c:304
    frame #2: 0x000000010dd6aa5f mono-sgen`mono_sigsegv_signal_handler_debug(_dummy=11, _info=0x000070000fb81c58, context=0x000070000fb81cc0, debug_fault_addr=0x000000010e28fb20) at mini-runtime.c:3540
    frame mono#3: 0x000000010dd6a8d3 mono-sgen`mono_sigsegv_signal_handler(_dummy=11, _info=0x000070000fb81c58, context=0x000070000fb81cc0) at mini-runtime.c:3612
    frame mono#4: 0x00007fff73dbdf5a libsystem_platform.dylib`_sigtramp + 26
    frame mono#5: 0x00007fff73bffa17 libsystem_kernel.dylib`__psynch_cvwait + 11
    frame mono#6: 0x00007fff73dc8589 libsystem_pthread.dylib`_pthread_cond_wait + 732
    frame mono#7: 0x000000010e28d76d mono-sgen`mono_os_cond_wait(cond=0x000000010e44c9d8, mutex=0x000000010e44c998) at mono-os-mutex.h:168
    frame mono#8: 0x000000010e28df4f mono-sgen`get_work(worker_index=0, work_context=0x000070000fb81ee0, do_idle=0x000070000fb81ed4, job=0x000070000fb81ec8) at sgen-thread-pool.c:165
    frame mono#9: 0x000000010e28d2cb mono-sgen`thread_func(data=0x0000000000000000) at sgen-thread-pool.c:196
    frame mono#10: 0x00007fff73dc7661 libsystem_pthread.dylib`_pthread_body + 340
    frame mono#11: 0x00007fff73dc750d libsystem_pthread.dylib`_pthread_start + 377
    frame mono#12: 0x00007fff73dc6bf9 libsystem_pthread.dylib`thread_start + 13
  thread mono#3, name = 'Finalizer'
    frame #0: 0x00007fff73bf6246 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x000000010e1d9c0a mono-sgen`mono_os_sem_wait(sem=0x000000010e43e400, flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:84
    frame #2: 0x000000010e1d832d mono-sgen`mono_coop_sem_wait(sem=0x000000010e43e400, flags=MONO_SEM_FLAGS_ALERTABLE) at mono-coop-semaphore.h:41
    frame mono#3: 0x000000010e1da787 mono-sgen`finalizer_thread(unused=0x0000000000000000) at gc.c:920
    frame mono#4: 0x000000010e152919 mono-sgen`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000070000fd85000) at threads.c:1178
    frame mono#5: 0x000000010e1525b6 mono-sgen`start_wrapper(data=0x00007faae4f31bd0) at threads.c:1238
    frame mono#6: 0x00007fff73dc7661 libsystem_pthread.dylib`_pthread_body + 340
    frame mono#7: 0x00007fff73dc750d libsystem_pthread.dylib`_pthread_start + 377
    frame mono#8: 0x00007fff73dc6bf9 libsystem_pthread.dylib`thread_start + 13
  thread mono#4
    frame #0: 0x00007fff73c0028a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff73dc7009 libsystem_pthread.dylib`_pthread_wqthread + 1035
    frame #2: 0x00007fff73dc6be9 libsystem_pthread.dylib`start_wqthread + 13
(lldb)
```

* [crash] Add signal-safe mmap/file "allocator"

* [crash] Remove use of static memory from dumper

* [runtime] Reduce print buffer size for lockless printer.

Each frame that prints ends up increased by the size of buff.
In practice, clang often fails to deduplicate some of these buffers,
leading to 30k-big stackframes.

It was noticed by a series of hard-to-diagnose segfaults on stacks that
looked otherwise fine during the crash reporting stress test.

This change fixes this, making stacks a 1/10th of the size. It doesn't
seem to break the crash reporter messages anywhere (may need to shrink
other "max name length" fields), and it's not mission-critical anywhere
else.

* [crash] Use async-safe file memory for dumper internals

* [crash] Add memory barriers around merp configuration

* [crash] Use signal-safe printers on all native crash paths

* [crash] Move gdb/lldb lookup to startup

* [runtime] Move MOSTLY_ASYNC_SAFE_FPRINTF to eglib

* [runtime] Fix all callsites of MOSTLY_ASYNC_SAFE_PRINTF

* [runtime] Fix all callsites of MOSTLY_ASYNC_SAFE_FPRINTF

* [crash] Switch to signal-safe exit function

* [crash] Make dumper enum in managed

* [runtime] Add more information to managed frame

* [crash] Make async_safe printers inlined

* [runtime] Move basic pe_file functionality into proclib

* [crash] Fix handling of thread attributes
lewurm pushed a commit that referenced this issue Feb 1, 2019
* [crash] Support extra merp params

* [runtime] Make infrastructure for merp tests

* [runtime] Fix dumping when crash happens without sigctx

* [runtime] Disable crashy (886/1000 runs) stacktrace walker

* [crash] Remove usage of allocating build/os info functions

* [crash] Remove often-crashing g_free on native crash path

* [crash] Add crash_reporter checked build

We add a checked build mode that asserts when mono mallocs inside of
the crash reporter. It makes risky allocations into assertions. It's
useful for automated testing because the double-abort often represents
itself as an indefinite hang. If it happens before the thread dumping
supervisor process is started, or after it ends, the crash reporter
hangs.

* [crash] Remove reliance on nested SIGABRT/double-fault (broken on OSX)

* [crash] Fix top-level handling of double faults/assertions

* [runtime] Make fatal unwinding errors return into handled error paths

* [crash] Change dumper logging for better info

* [runtime] Fix handling of segfault on sgen thread

Threads without domains that get segfaults will end up in
this handler. It's not safe to call this function with a NULL domain.

See crash below:

```
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x10eff40f8)
  * frame #0: 0x000000010e1510d9 mono-sgen`mono_threads_summarize_execute(ctx=0x0000000000000000, out=0x0000001000000000, hashes=0x0000100000100000, silent=4096, mem="", provided_size=2199023296512) at threads.c:6414
    frame #1: 0x000000010e152092 mono-sgen`mono_threads_summarize(ctx=0x000000010effda00, out=0x000000010effdba0, hashes=0x000000010effdb90, silent=0, signal_handler_controller=1, mem=0x0000000000000000, provided_size=0) at threads.c:6508
    frame #2: 0x000000010df7c69f mono-sgen`dump_native_stacktrace(signal="SIGSEGV", ctx=0x000000010effef48) at mini-posix.c:1026
    frame mono#3: 0x000000010df7c37f mono-sgen`mono_dump_native_crash_info(signal="SIGSEGV", ctx=0x000000010effef48, info=0x000000010effeee0) at mini-posix.c:1147
    frame mono#4: 0x000000010de720a9 mono-sgen`mono_handle_native_crash(signal="SIGSEGV", ctx=0x000000010effef48, info=0x000000010effeee0) at mini-exceptions.c:3227
    frame mono#5: 0x000000010dd6ac0d mono-sgen`mono_sigsegv_signal_handler_debug(_dummy=11, _info=0x000000010effeee0, context=0x000000010effef48, debug_fault_addr=0xffffffffffffffff) at mini-runtime.c:3574
    frame mono#6: 0x000000010dd6a8d3 mono-sgen`mono_sigsegv_signal_handler(_dummy=11, _info=0x000000010effeee0, context=0x000000010effef48) at mini-runtime.c:3612
    frame mono#7: 0x00007fff73dbdf5a libsystem_platform.dylib`_sigtramp + 26
    frame mono#8: 0x0000000110bb81c1
    frame mono#9: 0x000000011085ffe1
    frame mono#10: 0x000000010dd6d4f3 mono-sgen`mono_jit_runtime_invoke(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, exc=0x00007ffee1ea9f08, error=0x00007ffee1eaa250) at mini-runtime.c:3215
    frame mono#11: 0x000000010e11509d mono-sgen`do_runtime_invoke(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, exc=0x0000000000000000, error=0x00007ffee1eaa250) at object.c:2977
    frame mono#12: 0x000000010e10d961 mono-sgen`mono_runtime_invoke_checked(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, error=0x00007ffee1eaa250) at object.c:3145
    frame mono#13: 0x000000010e11aa58 mono-sgen`do_exec_main_checked(method=0x00007faae4f01fe8, args=0x000000010f0003e8, error=0x00007ffee1eaa250) at object.c:5042
    frame mono#14: 0x000000010e118803 mono-sgen`mono_runtime_exec_main_checked(method=0x00007faae4f01fe8, args=0x000000010f0003e8, error=0x00007ffee1eaa250) at object.c:5138
    frame mono#15: 0x000000010e118856 mono-sgen`mono_runtime_run_main_checked(method=0x00007faae4f01fe8, argc=2, argv=0x00007ffee1eaa760, error=0x00007ffee1eaa250) at object.c:4599
    frame mono#16: 0x000000010de1db2f mono-sgen`mono_jit_exec_internal(domain=0x00007faae4f00860, assembly=0x00007faae4c02ab0, argc=2, argv=0x00007ffee1eaa760) at driver.c:1298
    frame mono#17: 0x000000010de1d95d mono-sgen`mono_jit_exec(domain=0x00007faae4f00860, assembly=0x00007faae4c02ab0, argc=2, argv=0x00007ffee1eaa760) at driver.c:1257
    frame mono#18: 0x000000010de2257f mono-sgen`main_thread_handler(user_data=0x00007ffee1eaa6a0) at driver.c:1375
    frame mono#19: 0x000000010de20852 mono-sgen`mono_main(argc=3, argv=0x00007ffee1eaa758) at driver.c:2551
    frame mono#20: 0x000000010dd56d7e mono-sgen`mono_main_with_options(argc=3, argv=0x00007ffee1eaa758) at main.c:50
    frame mono#21: 0x000000010dd5638d mono-sgen`main(argc=3, argv=0x00007ffee1eaa758) at main.c:406
    frame mono#22: 0x00007fff73aaf015 libdyld.dylib`start + 1
    frame mono#23: 0x00007fff73aaf015 libdyld.dylib`start + 1
  thread #2, name = 'SGen worker'
    frame #0: 0x000000010e2afd77 mono-sgen`mono_get_hazardous_pointer(pp=0x0000000000000178, hp=0x000000010ef87618, hazard_index=0) at hazard-pointer.c:208
    frame #1: 0x000000010e0b28e1 mono-sgen`mono_jit_info_table_find_internal(domain=0x0000000000000000, addr=0x00007fff73bffa16, try_aot=1, allow_trampolines=1) at jit-info.c:304
    frame #2: 0x000000010dd6aa5f mono-sgen`mono_sigsegv_signal_handler_debug(_dummy=11, _info=0x000070000fb81c58, context=0x000070000fb81cc0, debug_fault_addr=0x000000010e28fb20) at mini-runtime.c:3540
    frame mono#3: 0x000000010dd6a8d3 mono-sgen`mono_sigsegv_signal_handler(_dummy=11, _info=0x000070000fb81c58, context=0x000070000fb81cc0) at mini-runtime.c:3612
    frame mono#4: 0x00007fff73dbdf5a libsystem_platform.dylib`_sigtramp + 26
    frame mono#5: 0x00007fff73bffa17 libsystem_kernel.dylib`__psynch_cvwait + 11
    frame mono#6: 0x00007fff73dc8589 libsystem_pthread.dylib`_pthread_cond_wait + 732
    frame mono#7: 0x000000010e28d76d mono-sgen`mono_os_cond_wait(cond=0x000000010e44c9d8, mutex=0x000000010e44c998) at mono-os-mutex.h:168
    frame mono#8: 0x000000010e28df4f mono-sgen`get_work(worker_index=0, work_context=0x000070000fb81ee0, do_idle=0x000070000fb81ed4, job=0x000070000fb81ec8) at sgen-thread-pool.c:165
    frame mono#9: 0x000000010e28d2cb mono-sgen`thread_func(data=0x0000000000000000) at sgen-thread-pool.c:196
    frame mono#10: 0x00007fff73dc7661 libsystem_pthread.dylib`_pthread_body + 340
    frame mono#11: 0x00007fff73dc750d libsystem_pthread.dylib`_pthread_start + 377
    frame mono#12: 0x00007fff73dc6bf9 libsystem_pthread.dylib`thread_start + 13
  thread mono#3, name = 'Finalizer'
    frame #0: 0x00007fff73bf6246 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x000000010e1d9c0a mono-sgen`mono_os_sem_wait(sem=0x000000010e43e400, flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:84
    frame #2: 0x000000010e1d832d mono-sgen`mono_coop_sem_wait(sem=0x000000010e43e400, flags=MONO_SEM_FLAGS_ALERTABLE) at mono-coop-semaphore.h:41
    frame mono#3: 0x000000010e1da787 mono-sgen`finalizer_thread(unused=0x0000000000000000) at gc.c:920
    frame mono#4: 0x000000010e152919 mono-sgen`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000070000fd85000) at threads.c:1178
    frame mono#5: 0x000000010e1525b6 mono-sgen`start_wrapper(data=0x00007faae4f31bd0) at threads.c:1238
    frame mono#6: 0x00007fff73dc7661 libsystem_pthread.dylib`_pthread_body + 340
    frame mono#7: 0x00007fff73dc750d libsystem_pthread.dylib`_pthread_start + 377
    frame mono#8: 0x00007fff73dc6bf9 libsystem_pthread.dylib`thread_start + 13
  thread mono#4
    frame #0: 0x00007fff73c0028a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff73dc7009 libsystem_pthread.dylib`_pthread_wqthread + 1035
    frame #2: 0x00007fff73dc6be9 libsystem_pthread.dylib`start_wqthread + 13
(lldb)
```

* [crash] Add signal-safe mmap/file "allocator"

* [crash] Remove use of static memory from dumper

* [runtime] Reduce print buffer size for lockless printer.

Each frame that prints ends up increased by the size of buff.
In practice, clang often fails to deduplicate some of these buffers,
leading to 30k-big stackframes.

It was noticed by a series of hard-to-diagnose segfaults on stacks that
looked otherwise fine during the crash reporting stress test.

This change fixes this, making stacks a 1/10th of the size. It doesn't
seem to break the crash reporter messages anywhere (may need to shrink
other "max name length" fields), and it's not mission-critical anywhere
else.

* [crash] Use async-safe file memory for dumper internals

* [crash] Add memory barriers around merp configuration

* [crash] Use signal-safe printers on all native crash paths

* [crash] Move gdb/lldb lookup to startup

* [runtime] Move MOSTLY_ASYNC_SAFE_FPRINTF to eglib

* [runtime] Fix all callsites of MOSTLY_ASYNC_SAFE_PRINTF

* [runtime] Fix all callsites of MOSTLY_ASYNC_SAFE_FPRINTF

* [crash] Switch to signal-safe exit function

* [crash] Make dumper enum in managed

* [runtime] Add more information to managed frame

* [crash] Make async_safe printers inlined

* [runtime] Move basic pe_file functionality into proclib

* [crash] Fix handling of thread attributes

* [crash] Place hashes into the json file for all threads

* [crash] Improve reporting on merp test

* [crash] Log the locations of written-to files, for better post-portems
lewurm pushed a commit that referenced this issue Feb 1, 2019
* [crash] Support extra merp params

* [runtime] Make infrastructure for merp tests

* [runtime] Fix dumping when crash happens without sigctx

* [runtime] Disable crashy (886/1000 runs) stacktrace walker

* [crash] Remove usage of allocating build/os info functions

* [crash] Remove often-crashing g_free on native crash path

* [crash] Add crash_reporter checked build

We add a checked build mode that asserts when mono mallocs inside of
the crash reporter. It makes risky allocations into assertions. It's
useful for automated testing because the double-abort often represents
itself as an indefinite hang. If it happens before the thread dumping
supervisor process is started, or after it ends, the crash reporter
hangs.

* [crash] Remove reliance on nested SIGABRT/double-fault (broken on OSX)

* [crash] Fix top-level handling of double faults/assertions

* [runtime] Make fatal unwinding errors return into handled error paths

* [crash] Change dumper logging for better info

* [runtime] Fix handling of segfault on sgen thread

Threads without domains that get segfaults will end up in
this handler. It's not safe to call this function with a NULL domain.

See crash below:

```
* thread #1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x10eff40f8)
  * frame #0: 0x000000010e1510d9 mono-sgen`mono_threads_summarize_execute(ctx=0x0000000000000000, out=0x0000001000000000, hashes=0x0000100000100000, silent=4096, mem="", provided_size=2199023296512) at threads.c:6414
    frame #1: 0x000000010e152092 mono-sgen`mono_threads_summarize(ctx=0x000000010effda00, out=0x000000010effdba0, hashes=0x000000010effdb90, silent=0, signal_handler_controller=1, mem=0x0000000000000000, provided_size=0) at threads.c:6508
    frame #2: 0x000000010df7c69f mono-sgen`dump_native_stacktrace(signal="SIGSEGV", ctx=0x000000010effef48) at mini-posix.c:1026
    frame mono#3: 0x000000010df7c37f mono-sgen`mono_dump_native_crash_info(signal="SIGSEGV", ctx=0x000000010effef48, info=0x000000010effeee0) at mini-posix.c:1147
    frame mono#4: 0x000000010de720a9 mono-sgen`mono_handle_native_crash(signal="SIGSEGV", ctx=0x000000010effef48, info=0x000000010effeee0) at mini-exceptions.c:3227
    frame mono#5: 0x000000010dd6ac0d mono-sgen`mono_sigsegv_signal_handler_debug(_dummy=11, _info=0x000000010effeee0, context=0x000000010effef48, debug_fault_addr=0xffffffffffffffff) at mini-runtime.c:3574
    frame mono#6: 0x000000010dd6a8d3 mono-sgen`mono_sigsegv_signal_handler(_dummy=11, _info=0x000000010effeee0, context=0x000000010effef48) at mini-runtime.c:3612
    frame mono#7: 0x00007fff73dbdf5a libsystem_platform.dylib`_sigtramp + 26
    frame mono#8: 0x0000000110bb81c1
    frame mono#9: 0x000000011085ffe1
    frame mono#10: 0x000000010dd6d4f3 mono-sgen`mono_jit_runtime_invoke(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, exc=0x00007ffee1ea9f08, error=0x00007ffee1eaa250) at mini-runtime.c:3215
    frame mono#11: 0x000000010e11509d mono-sgen`do_runtime_invoke(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, exc=0x0000000000000000, error=0x00007ffee1eaa250) at object.c:2977
    frame mono#12: 0x000000010e10d961 mono-sgen`mono_runtime_invoke_checked(method=0x00007faae4f01fe8, obj=0x0000000000000000, params=0x00007ffee1eaa180, error=0x00007ffee1eaa250) at object.c:3145
    frame mono#13: 0x000000010e11aa58 mono-sgen`do_exec_main_checked(method=0x00007faae4f01fe8, args=0x000000010f0003e8, error=0x00007ffee1eaa250) at object.c:5042
    frame mono#14: 0x000000010e118803 mono-sgen`mono_runtime_exec_main_checked(method=0x00007faae4f01fe8, args=0x000000010f0003e8, error=0x00007ffee1eaa250) at object.c:5138
    frame mono#15: 0x000000010e118856 mono-sgen`mono_runtime_run_main_checked(method=0x00007faae4f01fe8, argc=2, argv=0x00007ffee1eaa760, error=0x00007ffee1eaa250) at object.c:4599
    frame mono#16: 0x000000010de1db2f mono-sgen`mono_jit_exec_internal(domain=0x00007faae4f00860, assembly=0x00007faae4c02ab0, argc=2, argv=0x00007ffee1eaa760) at driver.c:1298
    frame mono#17: 0x000000010de1d95d mono-sgen`mono_jit_exec(domain=0x00007faae4f00860, assembly=0x00007faae4c02ab0, argc=2, argv=0x00007ffee1eaa760) at driver.c:1257
    frame mono#18: 0x000000010de2257f mono-sgen`main_thread_handler(user_data=0x00007ffee1eaa6a0) at driver.c:1375
    frame mono#19: 0x000000010de20852 mono-sgen`mono_main(argc=3, argv=0x00007ffee1eaa758) at driver.c:2551
    frame mono#20: 0x000000010dd56d7e mono-sgen`mono_main_with_options(argc=3, argv=0x00007ffee1eaa758) at main.c:50
    frame mono#21: 0x000000010dd5638d mono-sgen`main(argc=3, argv=0x00007ffee1eaa758) at main.c:406
    frame mono#22: 0x00007fff73aaf015 libdyld.dylib`start + 1
    frame mono#23: 0x00007fff73aaf015 libdyld.dylib`start + 1
  thread #2, name = 'SGen worker'
    frame #0: 0x000000010e2afd77 mono-sgen`mono_get_hazardous_pointer(pp=0x0000000000000178, hp=0x000000010ef87618, hazard_index=0) at hazard-pointer.c:208
    frame #1: 0x000000010e0b28e1 mono-sgen`mono_jit_info_table_find_internal(domain=0x0000000000000000, addr=0x00007fff73bffa16, try_aot=1, allow_trampolines=1) at jit-info.c:304
    frame #2: 0x000000010dd6aa5f mono-sgen`mono_sigsegv_signal_handler_debug(_dummy=11, _info=0x000070000fb81c58, context=0x000070000fb81cc0, debug_fault_addr=0x000000010e28fb20) at mini-runtime.c:3540
    frame mono#3: 0x000000010dd6a8d3 mono-sgen`mono_sigsegv_signal_handler(_dummy=11, _info=0x000070000fb81c58, context=0x000070000fb81cc0) at mini-runtime.c:3612
    frame mono#4: 0x00007fff73dbdf5a libsystem_platform.dylib`_sigtramp + 26
    frame mono#5: 0x00007fff73bffa17 libsystem_kernel.dylib`__psynch_cvwait + 11
    frame mono#6: 0x00007fff73dc8589 libsystem_pthread.dylib`_pthread_cond_wait + 732
    frame mono#7: 0x000000010e28d76d mono-sgen`mono_os_cond_wait(cond=0x000000010e44c9d8, mutex=0x000000010e44c998) at mono-os-mutex.h:168
    frame mono#8: 0x000000010e28df4f mono-sgen`get_work(worker_index=0, work_context=0x000070000fb81ee0, do_idle=0x000070000fb81ed4, job=0x000070000fb81ec8) at sgen-thread-pool.c:165
    frame mono#9: 0x000000010e28d2cb mono-sgen`thread_func(data=0x0000000000000000) at sgen-thread-pool.c:196
    frame mono#10: 0x00007fff73dc7661 libsystem_pthread.dylib`_pthread_body + 340
    frame mono#11: 0x00007fff73dc750d libsystem_pthread.dylib`_pthread_start + 377
    frame mono#12: 0x00007fff73dc6bf9 libsystem_pthread.dylib`thread_start + 13
  thread mono#3, name = 'Finalizer'
    frame #0: 0x00007fff73bf6246 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x000000010e1d9c0a mono-sgen`mono_os_sem_wait(sem=0x000000010e43e400, flags=MONO_SEM_FLAGS_ALERTABLE) at mono-os-semaphore.h:84
    frame #2: 0x000000010e1d832d mono-sgen`mono_coop_sem_wait(sem=0x000000010e43e400, flags=MONO_SEM_FLAGS_ALERTABLE) at mono-coop-semaphore.h:41
    frame mono#3: 0x000000010e1da787 mono-sgen`finalizer_thread(unused=0x0000000000000000) at gc.c:920
    frame mono#4: 0x000000010e152919 mono-sgen`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000070000fd85000) at threads.c:1178
    frame mono#5: 0x000000010e1525b6 mono-sgen`start_wrapper(data=0x00007faae4f31bd0) at threads.c:1238
    frame mono#6: 0x00007fff73dc7661 libsystem_pthread.dylib`_pthread_body + 340
    frame mono#7: 0x00007fff73dc750d libsystem_pthread.dylib`_pthread_start + 377
    frame mono#8: 0x00007fff73dc6bf9 libsystem_pthread.dylib`thread_start + 13
  thread mono#4
    frame #0: 0x00007fff73c0028a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007fff73dc7009 libsystem_pthread.dylib`_pthread_wqthread + 1035
    frame #2: 0x00007fff73dc6be9 libsystem_pthread.dylib`start_wqthread + 13
(lldb)
```

* [crash] Add signal-safe mmap/file "allocator"

* [crash] Remove use of static memory from dumper

* [runtime] Reduce print buffer size for lockless printer.

Each frame that prints ends up increased by the size of buff.
In practice, clang often fails to deduplicate some of these buffers,
leading to 30k-big stackframes.

It was noticed by a series of hard-to-diagnose segfaults on stacks that
looked otherwise fine during the crash reporting stress test.

This change fixes this, making stacks a 1/10th of the size. It doesn't
seem to break the crash reporter messages anywhere (may need to shrink
other "max name length" fields), and it's not mission-critical anywhere
else.

* [crash] Use async-safe file memory for dumper internals

* [crash] Add memory barriers around merp configuration

* [crash] Use signal-safe printers on all native crash paths

* [crash] Move gdb/lldb lookup to startup

* [runtime] Move MOSTLY_ASYNC_SAFE_FPRINTF to eglib

* [runtime] Fix all callsites of MOSTLY_ASYNC_SAFE_PRINTF

* [runtime] Fix all callsites of MOSTLY_ASYNC_SAFE_FPRINTF

* [crash] Switch to signal-safe exit function

* [crash] Make dumper enum in managed

* [runtime] Add more information to managed frame

* [crash] Make async_safe printers inlined

* [runtime] Move basic pe_file functionality into proclib

* [crash] Fix handling of thread attributes

* [crash] Place hashes into the json file for all threads

* [crash] Fix 2018-08 CI, disable test
lewurm pushed a commit that referenced this issue Apr 16, 2019
…13938)

The thread_stopped profiler event can be raised by the thread_info_key_dtor tls
key destructor when the thread is already doesn't have a domain set.  In that
case, don't call process_profiler_event since it cannot handle a thread with
null TLS values.

Addresses dotnet/android#2920
with the following stack trace

```
* thread mono#20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc)
  * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890
    frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595
    frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939
    frame mono#3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715
    frame mono#4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875
    frame mono#5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991
    frame mono#6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105
    frame mono#7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979
    frame mono#8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215
    frame mono#9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544
    frame mono#10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774
    frame mono#11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124
    frame mono#12: 0x00000072899c5374 libc.so`pthread_exit + 76
    frame mono#13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44
    frame mono#14: 0x000000728996617c libc.so`__start_thread + 72
```
lewurm pushed a commit that referenced this issue May 9, 2019
…14003)

The thread_stopped profiler event can be raised by the thread_info_key_dtor tls
key destructor when the thread is already doesn't have a domain set.  In that
case, don't call process_profiler_event since it cannot handle a thread with
null TLS values.

Addresses dotnet/android#2920
with the following stack trace

```
* thread mono#20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc)
  * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890
    frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595
    frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939
    frame mono#3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715
    frame mono#4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875
    frame mono#5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991
    frame mono#6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105
    frame mono#7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979
    frame mono#8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215
    frame mono#9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544
    frame mono#10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774
    frame mono#11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124
    frame mono#12: 0x00000072899c5374 libc.so`pthread_exit + 76
    frame mono#13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44
    frame mono#14: 0x000000728996617c libc.so`__start_thread + 72
```
lewurm pushed a commit that referenced this issue Jun 18, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls
key destructor when the thread is already doesn't have a domain set.  In that
case, don't call process_profiler_event since it cannot handle a thread with
null TLS values.

Addresses dotnet/android#2920
with the following stack trace

```
* thread mono#20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc)
  * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890
    frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595
    frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939
    frame mono#3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715
    frame mono#4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875
    frame mono#5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991
    frame mono#6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105
    frame mono#7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979
    frame mono#8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215
    frame mono#9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544
    frame mono#10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774
    frame mono#11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124
    frame mono#12: 0x00000072899c5374 libc.so`pthread_exit + 76
    frame mono#13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44
    frame mono#14: 0x000000728996617c libc.so`__start_thread + 72
```
lewurm pushed a commit that referenced this issue Jul 19, 2019
The thread_stopped profiler event can be raised by the thread_info_key_dtor tls
key destructor when the thread is already doesn't have a domain set.  In that
case, don't call process_profiler_event since it cannot handle a thread with
null TLS values.

Addresses dotnet/android#2920
with the following stack trace

```
* thread mono#20, name = 'Filter', stop reason = signal SIGSEGV: invalid address (fault address: 0xbc)
  * frame #0: libmonosgen-2.0.so`mono_class_vtable_checked(domain=0x0000000000000000, klass=0x0000007200230648, error=0x00000071e92f9178) at object.c:1890
    frame #1: libmonosgen-2.0.so`get_current_thread_ptr_for_domain(domain=0x0000000000000000, thread=0x00000071ebfec508) at threads.c:595
    frame #2: libmonosgen-2.0.so`mono_thread_current at threads.c:1939
    frame mono#3: libmonosgen-2.0.so`process_event(event=<unavailable>, arg=<unavailable>, il_offset=<unavailable>, ctx=<unavailable>, events=<unavailable>, suspend_policy=<unavailable>) at debugger-agent.c:3715
    frame mono#4: libmonosgen-2.0.so`thread_end [inlined] process_profiler_event(event=EVENT_KIND_THREAD_DEATH, arg=0x00000071ebfec508) at debugger-agent.c:3875
    frame mono#5: libmonosgen-2.0.so`thread_end(prof=<unavailable>, tid=<unavailable>) at debugger-agent.c:3991
    frame mono#6: libmonosgen-2.0.so`mono_profiler_raise_thread_stopped(tid=<unavailable>) at profiler-events.h:105
    frame mono#7: libmonosgen-2.0.so`mono_thread_detach_internal(thread=<unavailable>) at threads.c:979
    frame mono#8: libmonosgen-2.0.so`thread_detach(info=0x00000071e949a000) at threads.c:3215
    frame mono#9: libmonosgen-2.0.so`unregister_thread(arg=<unavailable>) at mono-threads.c:544
    frame mono#10: libmonosgen-2.0.so`thread_info_key_dtor(arg=0x00000071e949a000) at mono-threads.c:774
    frame mono#11: 0x00000072899c58e8 libc.so`pthread_key_clean_all() + 124
    frame mono#12: 0x00000072899c5374 libc.so`pthread_exit + 76
    frame mono#13: 0x00000072899c5264 libc.so`__pthread_start(void*) + 44
    frame mono#14: 0x000000728996617c libc.so`__start_thread + 72
```
lewurm added a commit that referenced this issue Aug 22, 2019
…lled with a cold calling convention."

This reverts commit ad86022. The commit was part of 870aec4 ( mono#16191 ).

It breaks `block_guard_restore_aligment_on_exit.exe` on Linux/AMD64 FullAOT+LLVM.

```
(lldb) p obj->vtable->klass->name
(const char *) $6 = 0x00007ffff431952a "ThreadAbortException"
(lldb) bt
* thread mono#4, name = 'mono-sgen', stop reason = step over
  * frame #0: 0x000055555587dfc8 mono-sgen`mono_handle_exception_internal(ctx=0x00007ffff2f89330, obj=0x00007ffff5c077f8, resume=0, out_ji=0x0000000000000000) at mini-exceptions.c:2485
    frame #1: 0x000055555587fbf1 mono-sgen`mono_handle_exception(ctx=0x00007ffff2f89330, void_obj=0x00007ffff5c077f8) at mini-exceptions.c:3034
    frame #2: 0x0000555555945ed6 mono-sgen`mono_amd64_throw_exception(dummy1=140737316419576, dummy2=140737269765200, dummy3=140737018598112, dummy4=0, dummy5=0, dummy6=0, mctx=0x00007ffff2f894f0, exc=0x00007ffff5c077f8, rethrow=1, preserve_ips=1) at exceptions-amd64.c:403
    frame mono#3: 0x00007ffff3ad091d mscorlib.dll.so`rethrow_preserve_exception + 173
    frame mono#4: 0x00007ffff2f8b648 block_guard_restore_aligment_on_exit.exe.so`icall_cold_wrapper_263 + 136
    frame mono#5: 0x00007ffff2f8bc3d block_guard_restore_aligment_on_exit.exe.so`Driver_InnerFunc + 141
    frame mono#6: 0x00007ffff2f8bd20 block_guard_restore_aligment_on_exit.exe.so`Driver_Func + 32
    frame mono#7: 0x00007ffff344c6d8 mscorlib.dll.so`System_Threading_ThreadHelper_ThreadStart_Context_object + 168
    frame mono#8: 0x00007ffff344a5c3 mscorlib.dll.so`System_Threading_ExecutionContext_Run_System_Threading_ExecutionContext_System_Threading_ContextCallback_object_bool + 35
    frame mono#9: 0x00007ffff344a555 mscorlib.dll.so`System_Threading_ExecutionContext_Run_System_Threading_ExecutionContext_System_Threading_ContextCallback_object + 53
    frame mono#10: 0x00007ffff344c7e8 mscorlib.dll.so`System_Threading_ThreadHelper_ThreadStart + 56
    frame mono#11: 0x00007ffff3ab2d92 mscorlib.dll.so`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 290
    frame mono#12: 0x000055555582e3ae mono-sgen`mono_jit_runtime_invoke(method=0x0000555557626f58, obj=0x00007ffff5c00630, params=0x00007ffff2f89df8, exc=0x00007ffff2f89ae0, error=0x00007ffff2f89e00) at mini-runtime.c:3152
    frame mono#13: 0x0000555555bb0da2 mono-sgen`do_runtime_invoke(method=0x0000555557626f58, obj=0x00007ffff5c00630, params=0x00007ffff2f89df8, exc=0x0000000000000000, error=0x00007ffff2f89e00) at object.c:3017
    frame mono#14: 0x0000555555bb1155 mono-sgen`mono_runtime_invoke_checked(method=0x0000555557626f58, obj=0x00007ffff5c00630, params=0x00007ffff2f89df8, error=0x00007ffff2f89e00) at object.c:3185
    frame mono#15: 0x0000555555bb3572 mono-sgen`mono_runtime_delegate_try_invoke(delegate=0x00007ffff5c00630, params=0x00007ffff2f89df8, exc=0x0000000000000000, error=0x00007ffff2f89e00) at object.c:4386
    frame mono#16: 0x0000555555bb3698 mono-sgen`mono_runtime_delegate_invoke_checked(delegate=0x00007ffff5c00630, params=0x00007ffff2f89df8, error=0x00007ffff2f89e00) at object.c:4417
    frame mono#17: 0x0000555555bd61be mono-sgen`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x00007ffff2f8b000) at threads.c:1242
    frame mono#18: 0x0000555555bd6334 mono-sgen`start_wrapper(data=0x000055555762ab80) at threads.c:1295
    frame mono#19: 0x00007ffff736a6db libpthread.so.0`start_thread + 219
    frame mono#20: 0x00007ffff675488f libc.so.6`__GI___clone at clone.S:95
```

EH doesn't know how to unwind `icall_cold_wrapper_263`.  Solution isn't obvious so let's revert it for now.
lewurm added a commit that referenced this issue Sep 13, 2019
Avoids this warning printed in the VSMac application output when debugging:
```
2019-09-13 17:47:27.315540+0200 aWatchOSExtension[31768:24665480] ../../../../../mono/eglib/giconv.c:1029: assertion 'str != NULL' failed
```

With this trace:
```
(lldb) mbt
* thread #2
  * frame #0: 0x00583453 aWatchOSExtension`break_on_me at giconv.c:1023:2
    frame #1: 0x005834a6 aWatchOSExtension`monoeg_g_utf16_to_utf8(str=0x00000000, len=0, items_read=0x00000000, items_written=0x00000000, err=0x00000000) at giconv.c:1036:3
    frame #2: 0x0046d871 aWatchOSExtension`mono_thread_get_name_utf8(thread=0x24d08120) at threads.c:1812:16
    frame mono#3: 0x002cb7ef aWatchOSExtension`thread_commands(command=2, p="�>\x02\x18\x10", end="�>\x02\x18\x10", buf=0xb0ae0d20) at debugger-agent.c:8818:13
    frame mono#4: 0x002c7170 aWatchOSExtension`debugger_thread(arg=0x00000000) at debugger-agent.c:9932:10
    frame mono#5: 0x0047652b aWatchOSExtension`start_wrapper_internal(start_info=0x00000000, stack_ptr=0xb0ae1000) at threads.c:1221:3
    frame mono#6: 0x0047616c aWatchOSExtension`start_wrapper(data=0x7b63a050) at threads.c:1294:8
    frame mono#7: 0x077365f8 libsystem_pthread.dylib`_pthread_body + 137
    frame mono#8: 0x077397f7 libsystem_pthread.dylib`_pthread_start + 78
    frame mono#9: 0x077357ce libsystem_pthread.dylib`thread_start + 34
```

Introduced by b5c0c83 and seemingly fixed by accident in mono@7b64f1c#diff-f1a9287559d3aa620b058619f47f00c9R1832

Instead of backporting 7b64f1c to 2019-08, I'm proposing this PR for the release branch.
lewurm added a commit that referenced this issue Sep 16, 2019
Avoids this warning:
```
2019-09-13 17:47:27.315540+0200 aWatchOSExtension[31768:24665480] ../../../../../mono/eglib/giconv.c:1029: assertion 'str != NULL' failed
```

with this trace:
```
(lldb) mbt
* thread #2
  * frame #0: 0x00583453 aWatchOSExtension`break_on_me at giconv.c:1023:2
    frame #1: 0x005834a6 aWatchOSExtension`monoeg_g_utf16_to_utf8(str=0x00000000, len=0, items_read=0x00000000, items_written=0x00000000, err=0x00000000) at giconv.c:1036:3
    frame #2: 0x0046d871 aWatchOSExtension`mono_thread_get_name_utf8(thread=0x24d08120) at threads.c:1812:16
    frame mono#3: 0x002cb7ef aWatchOSExtension`thread_commands(command=2, p="�>\x02\x18\x10", end="�>\x02\x18\x10", buf=0xb0ae0d20) at debugger-agent.c:8818:13
    frame mono#4: 0x002c7170 aWatchOSExtension`debugger_thread(arg=0x00000000) at debugger-agent.c:9932:10
    frame mono#5: 0x0047652b aWatchOSExtension`start_wrapper_internal(start_info=0x00000000, stack_ptr=0xb0ae1000) at threads.c:1221:3
    frame mono#6: 0x0047616c aWatchOSExtension`start_wrapper(data=0x7b63a050) at threads.c:1294:8
    frame mono#7: 0x077365f8 libsystem_pthread.dylib`_pthread_body + 137
    frame mono#8: 0x077397f7 libsystem_pthread.dylib`_pthread_start + 78
    frame mono#9: 0x077357ce libsystem_pthread.dylib`thread_start + 34
```
lewurm added a commit that referenced this issue Sep 19, 2019
Avoids this warning printed in the VSMac application output when debugging:
```
2019-09-13 17:47:27.315540+0200 aWatchOSExtension[31768:24665480] ../../../../../mono/eglib/giconv.c:1029: assertion 'str != NULL' failed
```

With this trace:
```
(lldb) mbt
* thread #2
  * frame #0: 0x00583453 aWatchOSExtension`break_on_me at giconv.c:1023:2
    frame #1: 0x005834a6 aWatchOSExtension`monoeg_g_utf16_to_utf8(str=0x00000000, len=0, items_read=0x00000000, items_written=0x00000000, err=0x00000000) at giconv.c:1036:3
    frame #2: 0x0046d871 aWatchOSExtension`mono_thread_get_name_utf8(thread=0x24d08120) at threads.c:1812:16
    frame mono#3: 0x002cb7ef aWatchOSExtension`thread_commands(command=2, p="�>\x02\x18\x10", end="�>\x02\x18\x10", buf=0xb0ae0d20) at debugger-agent.c:8818:13
    frame mono#4: 0x002c7170 aWatchOSExtension`debugger_thread(arg=0x00000000) at debugger-agent.c:9932:10
    frame mono#5: 0x0047652b aWatchOSExtension`start_wrapper_internal(start_info=0x00000000, stack_ptr=0xb0ae1000) at threads.c:1221:3
    frame mono#6: 0x0047616c aWatchOSExtension`start_wrapper(data=0x7b63a050) at threads.c:1294:8
    frame mono#7: 0x077365f8 libsystem_pthread.dylib`_pthread_body + 137
    frame mono#8: 0x077397f7 libsystem_pthread.dylib`_pthread_start + 78
    frame mono#9: 0x077357ce libsystem_pthread.dylib`thread_start + 34
```

Introduced by b5c0c83 and seemingly fixed by accident in mono@7b64f1c#diff-f1a9287559d3aa620b058619f47f00c9R1832

Instead of backporting 7b64f1c to 2019-08, I'm proposing this PR for the release branch.
lewurm added a commit that referenced this issue Sep 20, 2019
Note that in the output below `a`, `b`, etc. are NSObjects, so they are really passed as pointer.

Before:
```
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x04f301d4 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=0x00000000) at nsstring-localization.m:81:9
   78   void *
   79   xamarin_localized_string_format_9 (NSString *format, id a, id b, id c, id d, id e, id f, id g, id h, id i)
   80   {
-> 81           return [NSString localizedStringWithFormat: format, a, b, c, d, e, f, g, h, i];
   82   }
   83
   84   }
(lldb) mbt 4
* thread #1
  * frame #0: 0x04f301d4 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=0x00000000) at nsstring-localization.m:81:9
    frame #1: 0x04d9984c aWatchOSExtension`interp_to_native_trampoline + 156
    frame #2: 0x04f41d5c aWatchOSExtension`ves_pinvoke_method(frame=0x05167af8, sig=0x1518afd0, addr=(aWatchOSExtension`::xamarin_localized_string_format_9(NSString *, id, id, id, id, id, id, id, id, id) at nsstring-localization.m:80), string_ctor=0, context=0x14550960, save_last_error=0) at interp.c:1411:2 [opt]
    NSString::xamarin_localized_string_format_9 @ 68 "calli.nat" || frame mono#3: 0x04f3bfa4 aWatchOSExtension`interp_exec_method_full(frame=0x05167d38, context=<unavailable>, clause_args=0x00000000, error=0x05168540) at interp.c:3290:5 [opt]
```

After:
```
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x04c2c1e0 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=8) at nsstring-localization.m:81:9
   78   void *
   79   xamarin_localized_string_format_9 (NSString *format, id a, id b, id c, id d, id e, id f, id g, id h, id i)
   80   {
-> 81           return [NSString localizedStringWithFormat: format, a, b, c, d, e, f, g, h, i];
   82   }
   83
   84   }
```
lewurm added a commit that referenced this issue Sep 20, 2019
Note that in the output below `a`, `b`, etc. are NSObjects, so they are really passed as pointer.

Before:
```
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x04f301d4 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=0x00000000) at nsstring-localization.m:81:9
   78   void *
   79   xamarin_localized_string_format_9 (NSString *format, id a, id b, id c, id d, id e, id f, id g, id h, id i)
   80   {
-> 81           return [NSString localizedStringWithFormat: format, a, b, c, d, e, f, g, h, i];
   82   }
   83
   84   }
(lldb) mbt 4
* thread #1
  * frame #0: 0x04f301d4 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=0x00000000) at nsstring-localization.m:81:9
    frame #1: 0x04d9984c aWatchOSExtension`interp_to_native_trampoline + 156
    frame #2: 0x04f41d5c aWatchOSExtension`ves_pinvoke_method(frame=0x05167af8, sig=0x1518afd0, addr=(aWatchOSExtension`::xamarin_localized_string_format_9(NSString *, id, id, id, id, id, id, id, id, id) at nsstring-localization.m:80), string_ctor=0, context=0x14550960, save_last_error=0) at interp.c:1411:2 [opt]
    NSString::xamarin_localized_string_format_9 @ 68 "calli.nat" || frame mono#3: 0x04f3bfa4 aWatchOSExtension`interp_exec_method_full(frame=0x05167d38, context=<unavailable>, clause_args=0x00000000, error=0x05168540) at interp.c:3290:5 [opt]
```

After:
```
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x04c2c1e0 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=8) at nsstring-localization.m:81:9
   78   void *
   79   xamarin_localized_string_format_9 (NSString *format, id a, id b, id c, id d, id e, id f, id g, id h, id i)
   80   {
-> 81           return [NSString localizedStringWithFormat: format, a, b, c, d, e, f, g, h, i];
   82   }
   83
   84   }
```
lewurm added a commit that referenced this issue Sep 20, 2019
Fixes
```
* thread mono#12, name = 'tid_a507', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1be66144)
  * frame #0: 0x1be66144 libsystem_c.dylib`__abort + 184
    frame #1: 0x1be6608c libsystem_c.dylib`abort + 152
    frame #2: 0x003e1fa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="* Assertion at ../../../../../mono/utils/hazard-pointer.c:158, condition `mono_bitset_test_fast (small_id_table, id)' not met\n", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#3: 0x003abf44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#4: 0x003abfb4 monotouchtest`monoeg_assertion_message(format=<unavailable>) at goutput.c:184:22 [opt]
    frame mono#5: 0x003904dc monotouchtest`mono_thread_small_id_free(id=<unavailable>) at hazard-pointer.c:0:2 [opt]
    frame mono#6: 0x003a0a74 monotouchtest`unregister_thread(arg=0x15c88400) at mono-threads.c:588:2 [opt]
    frame mono#7: 0x00336110 monotouchtest`mono_thread_detach_if_exiting at threads.c:1571:4 [opt]
    frame mono#8: 0x003e7a14 monotouchtest`::xamarin_release_trampoline(self=0x166452f0, sel="release") at trampolines.m:644:3
    frame mono#9: 0x001cdc40 monotouchtest`::-[__Xamarin_NSTimerActionDispatcher release](self=0x166452f0, _cmd="release") at registrar.m:83445:3
    frame mono#10: 0x1ce2ae68 Foundation`_timerRelease + 80
    frame mono#11: 0x1c31b56c CoreFoundation`CFRunLoopTimerInvalidate + 612
    frame mono#12: 0x1c31a554 CoreFoundation`__CFRunLoopTimerDeallocate + 32
    frame mono#13: 0x1c31dde4 CoreFoundation`_CFRelease + 220
    frame mono#14: 0x1c2be6e8 CoreFoundation`__CFArrayReleaseValues + 500
    frame mono#15: 0x1c2be4c4 CoreFoundation`CFArrayRemoveAllValues + 104
    frame mono#16: 0x1c31ff64 CoreFoundation`__CFSetApplyFunction_block_invoke + 24
    frame mono#17: 0x1c3b2e18 CoreFoundation`CFBasicHashApply + 116
    frame mono#18: 0x1c31ff10 CoreFoundation`CFSetApplyFunction + 160
    frame mono#19: 0x1c3152cc CoreFoundation`__CFRunLoopDeallocate + 204
    frame mono#20: 0x1c31dde4 CoreFoundation`_CFRelease + 220
    frame mono#21: 0x1c304a80 CoreFoundation`__CFTSDFinalize + 144
    frame mono#22: 0x1bfa324c libsystem_pthread.dylib`_pthread_tsd_cleanup + 644
    frame mono#23: 0x1bf9cc08 libsystem_pthread.dylib`_pthread_exit + 80
    frame mono#24: 0x1bf9af24 libsystem_pthread.dylib`pthread_exit + 36
    frame mono#25: 0x0039df84 monotouchtest`mono_threads_platform_exit(exit_code=<unavailable>) at mono-threads-posix.c:145:2 [opt]
    frame mono#26: 0x0033bb84 monotouchtest`start_wrapper(data=0x1609e1c0) at threads.c:1296:2 [opt]
    frame mono#27: 0x1bf9b914 libsystem_pthread.dylib`_pthread_body + 128
    frame mono#28: 0x1bf9b874 libsystem_pthread.dylib`_pthread_start + 44
    frame mono#29: 0x1bfa3b94 libsystem_pthread.dylib`thread_start + 4
```
lewurm added a commit that referenced this issue Sep 20, 2019
Fixes
```
* thread mono#12, name = 'tid_a507', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1be66144)
  * frame #0: 0x1be66144 libsystem_c.dylib`__abort + 184
    frame #1: 0x1be6608c libsystem_c.dylib`abort + 152
    frame #2: 0x003e1fa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="* Assertion at ../../../../../mono/utils/hazard-pointer.c:158, condition `mono_bitset_test_fast (small_id_table, id)' not met\n", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#3: 0x003abf44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#4: 0x003abfb4 monotouchtest`monoeg_assertion_message(format=<unavailable>) at goutput.c:184:22 [opt]
    frame mono#5: 0x003904dc monotouchtest`mono_thread_small_id_free(id=<unavailable>) at hazard-pointer.c:0:2 [opt]
    frame mono#6: 0x003a0a74 monotouchtest`unregister_thread(arg=0x15c88400) at mono-threads.c:588:2 [opt]
    frame mono#7: 0x00336110 monotouchtest`mono_thread_detach_if_exiting at threads.c:1571:4 [opt]
    frame mono#8: 0x003e7a14 monotouchtest`::xamarin_release_trampoline(self=0x166452f0, sel="release") at trampolines.m:644:3
    frame mono#9: 0x001cdc40 monotouchtest`::-[__Xamarin_NSTimerActionDispatcher release](self=0x166452f0, _cmd="release") at registrar.m:83445:3
    frame mono#10: 0x1ce2ae68 Foundation`_timerRelease + 80
    frame mono#11: 0x1c31b56c CoreFoundation`CFRunLoopTimerInvalidate + 612
    frame mono#12: 0x1c31a554 CoreFoundation`__CFRunLoopTimerDeallocate + 32
    frame mono#13: 0x1c31dde4 CoreFoundation`_CFRelease + 220
    frame mono#14: 0x1c2be6e8 CoreFoundation`__CFArrayReleaseValues + 500
    frame mono#15: 0x1c2be4c4 CoreFoundation`CFArrayRemoveAllValues + 104
    frame mono#16: 0x1c31ff64 CoreFoundation`__CFSetApplyFunction_block_invoke + 24
    frame mono#17: 0x1c3b2e18 CoreFoundation`CFBasicHashApply + 116
    frame mono#18: 0x1c31ff10 CoreFoundation`CFSetApplyFunction + 160
    frame mono#19: 0x1c3152cc CoreFoundation`__CFRunLoopDeallocate + 204
    frame mono#20: 0x1c31dde4 CoreFoundation`_CFRelease + 220
    frame mono#21: 0x1c304a80 CoreFoundation`__CFTSDFinalize + 144
    frame mono#22: 0x1bfa324c libsystem_pthread.dylib`_pthread_tsd_cleanup + 644
    frame mono#23: 0x1bf9cc08 libsystem_pthread.dylib`_pthread_exit + 80
    frame mono#24: 0x1bf9af24 libsystem_pthread.dylib`pthread_exit + 36
    frame mono#25: 0x0039df84 monotouchtest`mono_threads_platform_exit(exit_code=<unavailable>) at mono-threads-posix.c:145:2 [opt]
    frame mono#26: 0x0033bb84 monotouchtest`start_wrapper(data=0x1609e1c0) at threads.c:1296:2 [opt]
    frame mono#27: 0x1bf9b914 libsystem_pthread.dylib`_pthread_body + 128
    frame mono#28: 0x1bf9b874 libsystem_pthread.dylib`_pthread_start + 44
    frame mono#29: 0x1bfa3b94 libsystem_pthread.dylib`thread_start + 4
```
lewurm added a commit that referenced this issue Sep 24, 2019
Note that in the output below `a`, `b`, etc. are NSObjects, so they are really passed as pointer.

Before:
```
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x04f301d4 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=0x00000000) at nsstring-localization.m:81:9
   78   void *
   79   xamarin_localized_string_format_9 (NSString *format, id a, id b, id c, id d, id e, id f, id g, id h, id i)
   80   {
-> 81           return [NSString localizedStringWithFormat: format, a, b, c, d, e, f, g, h, i];
   82   }
   83
   84   }
(lldb) mbt 4
* thread #1
  * frame #0: 0x04f301d4 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=0x00000000) at nsstring-localization.m:81:9
    frame #1: 0x04d9984c aWatchOSExtension`interp_to_native_trampoline + 156
    frame #2: 0x04f41d5c aWatchOSExtension`ves_pinvoke_method(frame=0x05167af8, sig=0x1518afd0, addr=(aWatchOSExtension`::xamarin_localized_string_format_9(NSString *, id, id, id, id, id, id, id, id, id) at nsstring-localization.m:80), string_ctor=0, context=0x14550960, save_last_error=0) at interp.c:1411:2 [opt]
    NSString::xamarin_localized_string_format_9 @ 68 "calli.nat" || frame mono#3: 0x04f3bfa4 aWatchOSExtension`interp_exec_method_full(frame=0x05167d38, context=<unavailable>, clause_args=0x00000000, error=0x05168540) at interp.c:3290:5 [opt]
```

After:
```
* thread #1, name = 'tid_303', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x04c2c1e0 aWatchOSExtension`::xamarin_localized_string_format_9(format="hello%@%@%@%@%@%@%@%@%@", a=0, b=1, c=2, d=3, e=4, f=5, g=6, h=7, i=8) at nsstring-localization.m:81:9
   78   void *
   79   xamarin_localized_string_format_9 (NSString *format, id a, id b, id c, id d, id e, id f, id g, id h, id i)
   80   {
-> 81           return [NSString localizedStringWithFormat: format, a, b, c, d, e, f, g, h, i];
   82   }
   83
   84   }
```
lewurm added a commit that referenced this issue Sep 24, 2019
)

* [threads] clear small_id_key TLS when unregistering a thread

Fixes
```
* thread mono#12, name = 'tid_a507', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1be66144)
  * frame #0: 0x1be66144 libsystem_c.dylib`__abort + 184
    frame #1: 0x1be6608c libsystem_c.dylib`abort + 152
    frame #2: 0x003e1fa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="* Assertion at ../../../../../mono/utils/hazard-pointer.c:158, condition `mono_bitset_test_fast (small_id_table, id)' not met\n", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#3: 0x003abf44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#4: 0x003abfb4 monotouchtest`monoeg_assertion_message(format=<unavailable>) at goutput.c:184:22 [opt]
    frame mono#5: 0x003904dc monotouchtest`mono_thread_small_id_free(id=<unavailable>) at hazard-pointer.c:0:2 [opt]
    frame mono#6: 0x003a0a74 monotouchtest`unregister_thread(arg=0x15c88400) at mono-threads.c:588:2 [opt]
    frame mono#7: 0x00336110 monotouchtest`mono_thread_detach_if_exiting at threads.c:1571:4 [opt]
    frame mono#8: 0x003e7a14 monotouchtest`::xamarin_release_trampoline(self=0x166452f0, sel="release") at trampolines.m:644:3
    frame mono#9: 0x001cdc40 monotouchtest`::-[__Xamarin_NSTimerActionDispatcher release](self=0x166452f0, _cmd="release") at registrar.m:83445:3
    frame mono#10: 0x1ce2ae68 Foundation`_timerRelease + 80
    frame mono#11: 0x1c31b56c CoreFoundation`CFRunLoopTimerInvalidate + 612
    frame mono#12: 0x1c31a554 CoreFoundation`__CFRunLoopTimerDeallocate + 32
    frame mono#13: 0x1c31dde4 CoreFoundation`_CFRelease + 220
    frame mono#14: 0x1c2be6e8 CoreFoundation`__CFArrayReleaseValues + 500
    frame mono#15: 0x1c2be4c4 CoreFoundation`CFArrayRemoveAllValues + 104
    frame mono#16: 0x1c31ff64 CoreFoundation`__CFSetApplyFunction_block_invoke + 24
    frame mono#17: 0x1c3b2e18 CoreFoundation`CFBasicHashApply + 116
    frame mono#18: 0x1c31ff10 CoreFoundation`CFSetApplyFunction + 160
    frame mono#19: 0x1c3152cc CoreFoundation`__CFRunLoopDeallocate + 204
    frame mono#20: 0x1c31dde4 CoreFoundation`_CFRelease + 220
    frame mono#21: 0x1c304a80 CoreFoundation`__CFTSDFinalize + 144
    frame mono#22: 0x1bfa324c libsystem_pthread.dylib`_pthread_tsd_cleanup + 644
    frame mono#23: 0x1bf9cc08 libsystem_pthread.dylib`_pthread_exit + 80
    frame mono#24: 0x1bf9af24 libsystem_pthread.dylib`pthread_exit + 36
    frame mono#25: 0x0039df84 monotouchtest`mono_threads_platform_exit(exit_code=<unavailable>) at mono-threads-posix.c:145:2 [opt]
    frame mono#26: 0x0033bb84 monotouchtest`start_wrapper(data=0x1609e1c0) at threads.c:1296:2 [opt]
    frame mono#27: 0x1bf9b914 libsystem_pthread.dylib`_pthread_body + 128
    frame mono#28: 0x1bf9b874 libsystem_pthread.dylib`_pthread_start + 44
    frame mono#29: 0x1bfa3b94 libsystem_pthread.dylib`thread_start + 4
```

* Update mono/utils/mono-threads.c

Co-Authored-By: Aleksey Kliger (λgeek) <akliger@gmail.com>
lewurm added a commit that referenced this issue Oct 7, 2019
Instead of:

```
(lldb) mbt 20
* thread mono#11
  * frame #0: 0x1bf28f28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x1bf9caac libsystem_pthread.dylib`pthread_kill + 300
    frame #2: 0x1be66080 libsystem_c.dylib`abort + 140
    frame mono#3: 0x024bdfa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="../../../../../mono/metadata/object.c:1905: Expected GC Unsafe mode but was in STATE_BLOCKING state", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#4: 0x02487f44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#5: 0x02487ee0 monotouchtest`monoeg_g_logv(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>, args=<unavailable>) at goutput.c:156:10 [opt]
    frame mono#6: 0x02487f74 monotouchtest`monoeg_g_log(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>) at goutput.c:165:2 [opt]
    frame mono#7: 0x024694c4 monotouchtest`assert_gc_unsafe_mode(file="../../../../../mono/metadata/object.c", lineno=1905) at checked-build.c:396:3 [opt]
    frame mono#8: 0x023d2f64 monotouchtest`mono_class_vtable_checked(domain=0x16d64800, klass=0x173c1b98, error=0x194b0ee8) at object.c:1905:2 [opt]
    frame mono#9: 0x024130a8 monotouchtest`get_current_thread_ptr_for_domain(domain=0x16d64800, thread=0x02db45d0) at threads.c:635:2 [opt]
    frame mono#10: 0x024119a8 monotouchtest`mono_thread_current at threads.c:2026:23 [opt]
    frame mono#11: 0x02416998 monotouchtest`mono_thread_interruption_checkpoint_request(bypass_abort_protection=0) at threads.c:5101:35 [opt]
    Messaging::void_objc_msgSendSuper @ 388435850 "calli.nat.fast" || frame mono#12: 0x024d5de8 monotouchtest`interp_exec_method_full(frame=0x194b11c0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3230:4 [opt]
    ObjCExceptionTest::InvokeManagedExceptionThrower @ 388435752 "vcall" || frame mono#13: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1380, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    ExceptionsTest::ManagedExceptionPassthrough @ 388502134 "vcallvirt.fast" || frame mono#14: 0x024d61c0 monotouchtest`interp_exec_method_full(frame=0x194b14e0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3325:4 [opt]
    Object::runtime_invoke_direct_void__this__ @ 388462550 "vcall" || frame mono#15: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1598, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    frame mono#16: 0x024d46ec monotouchtest`interp_runtime_invoke(method=<unavailable>, obj=0x0302c5f0, params=0x00000000, exc=0x194b166c, error=0x194b18c8) at interp.c:1766:2 [opt]
    frame mono#17: 0x0232b39c monotouchtest`mono_jit_runtime_invoke(method=0x174fda58, obj=<unavailable>, params=0x00000000, exc=<unavailable>, error=0x194b18c8) at mini-runtime.c:3170:12 [opt]
    frame mono#18: 0x023d5cc8 monotouchtest`do_runtime_invoke(method=0x174fda58, obj=0x0302c5f0, params=0x00000000, exc=0x00000000, error=0x194b18c8) at object.c:3017:11 [opt]
    frame mono#19: 0x023d26a0 monotouchtest`mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at class-getters.h:24:1 [opt] [artificial]
```

It prints now:

```
(lldb) mbt 20
* thread mono#11
  * frame #0: 0x1bf28f28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x1bf9caac libsystem_pthread.dylib`pthread_kill + 300
    frame #2: 0x1be66080 libsystem_c.dylib`abort + 140
    frame mono#3: 0x024bdfa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="../../../../../mono/metadata/object.c:1905: Expected GC Unsafe mode but was in STATE_BLOCKING state", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#4: 0x02487f44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#5: 0x02487ee0 monotouchtest`monoeg_g_logv(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>, args=<unavailable>) at goutput.c:156:10 [opt]
    frame mono#6: 0x02487f74 monotouchtest`monoeg_g_log(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>) at goutput.c:165:2 [opt]
    frame mono#7: 0x024694c4 monotouchtest`assert_gc_unsafe_mode(file="../../../../../mono/metadata/object.c", lineno=1905) at checked-build.c:396:3 [opt]
    frame mono#8: 0x023d2f64 monotouchtest`mono_class_vtable_checked(domain=0x16d64800, klass=0x173c1b98, error=0x194b0ee8) at object.c:1905:2 [opt]
    frame mono#9: 0x024130a8 monotouchtest`get_current_thread_ptr_for_domain(domain=0x16d64800, thread=0x02db45d0) at threads.c:635:2 [opt]
    frame mono#10: 0x024119a8 monotouchtest`mono_thread_current at threads.c:2026:23 [opt]
    frame mono#11: 0x02416998 monotouchtest`mono_thread_interruption_checkpoint_request(bypass_abort_protection=0) at threads.c:5101:35 [opt]
    (wrapper managed-to-native) ApiDefinition.Messaging:void_objc_msgSendSuper (intptr,intptr) @ 388435850 "calli.nat.fast" || frame mono#12: 0x024d5de8 monotouchtest`interp_exec_method_full(frame=0x194b11c0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3230:4 [opt]
    Bindings.Test.ObjCExceptionTest:InvokeManagedExceptionThrower () @ 388435752 "vcall" || frame mono#13: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1380, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    MonoTouchFixtures.ObjCRuntime.ExceptionsTest:ManagedExceptionPassthrough () @ 388502134 "vcallvirt.fast" || frame mono#14: 0x024d61c0 monotouchtest`interp_exec_method_full(frame=0x194b14e0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3325:4 [opt]
    (wrapper runtime-invoke) object:runtime_invoke_direct_void__this__ (object,intptr,intptr,intptr) @ 388462550 "vcall" || frame mono#15: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1598, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    frame mono#16: 0x024d46ec monotouchtest`interp_runtime_invoke(method=<unavailable>, obj=0x0302c5f0, params=0x00000000, exc=0x194b166c, error=0x194b18c8) at interp.c:1766:2 [opt]
    frame mono#17: 0x0232b39c monotouchtest`mono_jit_runtime_invoke(method=0x174fda58, obj=<unavailable>, params=0x00000000, exc=<unavailable>, error=0x194b18c8) at mini-runtime.c:3170:12 [opt]
    frame mono#18: 0x023d5cc8 monotouchtest`do_runtime_invoke(method=0x174fda58, obj=0x0302c5f0, params=0x00000000, exc=0x00000000, error=0x194b18c8) at object.c:3017:11 [opt]
    frame mono#19: 0x023d26a0 monotouchtest`mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at class-getters.h:24:1 [opt] [artificial]
```
lewurm added a commit that referenced this issue Oct 9, 2019
[lldb] use mono_method_full_name helper

Instead of:

```
(lldb) mbt 20
* thread mono#11
  * frame #0: 0x1bf28f28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x1bf9caac libsystem_pthread.dylib`pthread_kill + 300
    frame #2: 0x1be66080 libsystem_c.dylib`abort + 140
    frame mono#3: 0x024bdfa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="../../../../../mono/metadata/object.c:1905: Expected GC Unsafe mode but was in STATE_BLOCKING state", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#4: 0x02487f44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#5: 0x02487ee0 monotouchtest`monoeg_g_logv(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>, args=<unavailable>) at goutput.c:156:10 [opt]
    frame mono#6: 0x02487f74 monotouchtest`monoeg_g_log(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>) at goutput.c:165:2 [opt]
    frame mono#7: 0x024694c4 monotouchtest`assert_gc_unsafe_mode(file="../../../../../mono/metadata/object.c", lineno=1905) at checked-build.c:396:3 [opt]
    frame mono#8: 0x023d2f64 monotouchtest`mono_class_vtable_checked(domain=0x16d64800, klass=0x173c1b98, error=0x194b0ee8) at object.c:1905:2 [opt]
    frame mono#9: 0x024130a8 monotouchtest`get_current_thread_ptr_for_domain(domain=0x16d64800, thread=0x02db45d0) at threads.c:635:2 [opt]
    frame mono#10: 0x024119a8 monotouchtest`mono_thread_current at threads.c:2026:23 [opt]
    frame mono#11: 0x02416998 monotouchtest`mono_thread_interruption_checkpoint_request(bypass_abort_protection=0) at threads.c:5101:35 [opt]
    Messaging::void_objc_msgSendSuper @ 388435850 "calli.nat.fast" || frame mono#12: 0x024d5de8 monotouchtest`interp_exec_method_full(frame=0x194b11c0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3230:4 [opt]
    ObjCExceptionTest::InvokeManagedExceptionThrower @ 388435752 "vcall" || frame mono#13: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1380, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    ExceptionsTest::ManagedExceptionPassthrough @ 388502134 "vcallvirt.fast" || frame mono#14: 0x024d61c0 monotouchtest`interp_exec_method_full(frame=0x194b14e0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3325:4 [opt]
    Object::runtime_invoke_direct_void__this__ @ 388462550 "vcall" || frame mono#15: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1598, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    frame mono#16: 0x024d46ec monotouchtest`interp_runtime_invoke(method=<unavailable>, obj=0x0302c5f0, params=0x00000000, exc=0x194b166c, error=0x194b18c8) at interp.c:1766:2 [opt]
    frame mono#17: 0x0232b39c monotouchtest`mono_jit_runtime_invoke(method=0x174fda58, obj=<unavailable>, params=0x00000000, exc=<unavailable>, error=0x194b18c8) at mini-runtime.c:3170:12 [opt]
    frame mono#18: 0x023d5cc8 monotouchtest`do_runtime_invoke(method=0x174fda58, obj=0x0302c5f0, params=0x00000000, exc=0x00000000, error=0x194b18c8) at object.c:3017:11 [opt]
    frame mono#19: 0x023d26a0 monotouchtest`mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at class-getters.h:24:1 [opt] [artificial]
```

It prints now:

```
(lldb) mbt 20
* thread mono#11
  * frame #0: 0x1bf28f28 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x1bf9caac libsystem_pthread.dylib`pthread_kill + 300
    frame #2: 0x1be66080 libsystem_c.dylib`abort + 140
    frame mono#3: 0x024bdfa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="../../../../../mono/metadata/object.c:1905: Expected GC Unsafe mode but was in STATE_BLOCKING state", fatal=4, user_data=0x00000000) at runtime.m:1251:3
    frame mono#4: 0x02487f44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt]
    frame mono#5: 0x02487ee0 monotouchtest`monoeg_g_logv(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>, args=<unavailable>) at goutput.c:156:10 [opt]
    frame mono#6: 0x02487f74 monotouchtest`monoeg_g_log(log_domain=<unavailable>, log_level=<unavailable>, format=<unavailable>) at goutput.c:165:2 [opt]
    frame mono#7: 0x024694c4 monotouchtest`assert_gc_unsafe_mode(file="../../../../../mono/metadata/object.c", lineno=1905) at checked-build.c:396:3 [opt]
    frame mono#8: 0x023d2f64 monotouchtest`mono_class_vtable_checked(domain=0x16d64800, klass=0x173c1b98, error=0x194b0ee8) at object.c:1905:2 [opt]
    frame mono#9: 0x024130a8 monotouchtest`get_current_thread_ptr_for_domain(domain=0x16d64800, thread=0x02db45d0) at threads.c:635:2 [opt]
    frame mono#10: 0x024119a8 monotouchtest`mono_thread_current at threads.c:2026:23 [opt]
    frame mono#11: 0x02416998 monotouchtest`mono_thread_interruption_checkpoint_request(bypass_abort_protection=0) at threads.c:5101:35 [opt]
    (wrapper managed-to-native) ApiDefinition.Messaging:void_objc_msgSendSuper (intptr,intptr) @ 388435850 "calli.nat.fast" || frame mono#12: 0x024d5de8 monotouchtest`interp_exec_method_full(frame=0x194b11c0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3230:4 [opt]
    Bindings.Test.ObjCExceptionTest:InvokeManagedExceptionThrower () @ 388435752 "vcall" || frame mono#13: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1380, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    MonoTouchFixtures.ObjCRuntime.ExceptionsTest:ManagedExceptionPassthrough () @ 388502134 "vcallvirt.fast" || frame mono#14: 0x024d61c0 monotouchtest`interp_exec_method_full(frame=0x194b14e0, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3325:4 [opt]
    (wrapper runtime-invoke) object:runtime_invoke_direct_void__this__ (object,intptr,intptr,intptr) @ 388462550 "vcall" || frame mono#15: 0x024d64dc monotouchtest`interp_exec_method_full(frame=0x194b1598, context=<unavailable>, clause_args=<unavailable>, error=<unavailable>) at interp.c:3400:4 [opt]
    frame mono#16: 0x024d46ec monotouchtest`interp_runtime_invoke(method=<unavailable>, obj=0x0302c5f0, params=0x00000000, exc=0x194b166c, error=0x194b18c8) at interp.c:1766:2 [opt]
    frame mono#17: 0x0232b39c monotouchtest`mono_jit_runtime_invoke(method=0x174fda58, obj=<unavailable>, params=0x00000000, exc=<unavailable>, error=0x194b18c8) at mini-runtime.c:3170:12 [opt]
    frame mono#18: 0x023d5cc8 monotouchtest`do_runtime_invoke(method=0x174fda58, obj=0x0302c5f0, params=0x00000000, exc=0x00000000, error=0x194b18c8) at object.c:3017:11 [opt]
    frame mono#19: 0x023d26a0 monotouchtest`mono_runtime_invoke_checked(method=<unavailable>, obj=<unavailable>, params=<unavailable>, error=<unavailable>) at class-getters.h:24:1 [opt] [artificial]
```



<!--
Thank you for your Pull Request!

If you are new to contributing to Mono, please try to do your best at conforming to our coding guidelines http://www.mono-project.com/community/contributing/coding-guidelines/ but don't worry if you get something wrong. One of the project members will help you to get things landed.

Does your pull request fix any of the existing issues? Please use the following format: Fixes #issue-number
-->
lewurm added a commit that referenced this issue Dec 9, 2019
```
* thread mono#8, name = 'tid_1007'
  * frame #0: 0x65f7e3d2 libsystem_kernel.dylib`semaphore_wait_trap + 10
    frame #1: 0x00516c3a WatchWCSessionAppWatchOSExtension`mono_os_sem_wait(sem=0x8210962c, flags=MONO_SEM_FLAGS_NONE) at mono-os-semaphore.h:84:8
    frame #2: 0x00516bb2 WatchWCSessionAppWatchOSExtension`mono_thread_info_wait_for_resume(info=0x82109600) at mono-threads.c:232:8
    frame mono#3: 0x005125cf WatchWCSessionAppWatchOSExtension`mono_threads_enter_gc_unsafe_region_unbalanced_with_info(info=0x82109600, stackdata=0xb0c22ef8) at mono-threads-coop.c:498:3
    frame mono#4: 0x00518228 WatchWCSessionAppWatchOSExtension`unregister_thread(arg=0x82109600) at mono-threads.c:527:2
    frame mono#5: 0x00518c49 WatchWCSessionAppWatchOSExtension`thread_info_key_dtor(arg=0x82109600) at mono-threads.c:796:2
    frame mono#6: 0x66025c2f libsystem_pthread.dylib`_pthread_tsd_cleanup + 537
    frame mono#7: 0x66028c27 libsystem_pthread.dylib`_pthread_exit + 68
    frame mono#8: 0x660259d4 libsystem_pthread.dylib`_pthread_wqthread_exit + 71
    frame mono#9: 0x66025074 libsystem_pthread.dylib`_pthread_wqthread + 420
    frame mono#10: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```
lewurm added a commit that referenced this issue Dec 9, 2019
When the debugger tries to suspend all the VM threads, it can happen with cooperative-suspend that it tries to suspend a thread that has previously been attached, but then did a "light" detach (that only unsets the domain). With the domain set to `NULL`, looking up a JitInfo for a given `ip` will result into a crash, but it isn't even necessarily needed for the purpose of suspending a thread.

More details: Consider the following:
```
(lldb) c
error: Process is running.  Use 'process interrupt' to pause execution.
Process 12832 stopped
* thread mono#9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
    frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6
   2713         MonoDomain *domain = (MonoDomain *) mono_thread_info_get_suspend_state (info)->unwind_data [MONO_UNWIND_DATA_DOMAIN];
   2714         if (!domain) {
   2715                 /* not attached */
-> 2716                 ji = NULL;
   2717         } else {
   2718                 ji = mono_jit_info_table_find_internal ( domain, MONO_CONTEXT_GET_IP (&mono_thread_info_get_suspend_state (info)->ctx), TRUE, TRUE);
   2719         }
Target 0: (WatchWCSessionAppWatchOSExtension) stopped.
(lldb) bt
* thread mono#9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
  * frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6
    frame #1: 0x004e177b WatchWCSessionAppWatchOSExtension`mono_thread_info_safe_suspend_and_run(id=0xb0767000, interrupt_kernel=0, callback=(WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical at debugger-agent.c:2708), user_data=0xb04dc718) at mono-threads.c:1358:19
    frame #2: 0x00222799 WatchWCSessionAppWatchOSExtension`notify_thread(key=0x03994508, value=0x81378c00, user_data=0x00000000) at debugger-agent.c:2747:2
    frame mono#3: 0x00355bd8 WatchWCSessionAppWatchOSExtension`mono_g_hash_table_foreach(hash=0x8007b4e0, func=(WatchWCSessionAppWatchOSExtension`notify_thread at debugger-agent.c:2733), user_data=0x00000000) at mono-hash.c:310:4
    frame mono#4: 0x0021e955 WatchWCSessionAppWatchOSExtension`suspend_vm at debugger-agent.c:2844:3
    frame mono#5: 0x00225ff0 WatchWCSessionAppWatchOSExtension`process_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0, il_offset=0, ctx=0x00000000, events=0x805b28e0, suspend_policy=2) at debugger-agent.c:4012:3
    frame mono#6: 0x00227c7c WatchWCSessionAppWatchOSExtension`process_profiler_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0) at debugger-agent.c:4072:2
    frame mono#7: 0x0021b174 WatchWCSessionAppWatchOSExtension`thread_startup(prof=0x00000000, tid=2957889536) at debugger-agent.c:4149:2
    frame mono#8: 0x0037912d WatchWCSessionAppWatchOSExtension`mono_profiler_raise_thread_started(tid=2957889536) at profiler-events.h:103:1
    frame mono#9: 0x003d53da WatchWCSessionAppWatchOSExtension`fire_attach_profiler_events(tid=0xb04dd000) at threads.c:1120:2
    frame mono#10: 0x003d4d83 WatchWCSessionAppWatchOSExtension`mono_thread_attach(domain=0x801750a0) at threads.c:1547:2
    frame mono#11: 0x003df1a1 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop_internal(domain=0x801750a0, cookie=0xb04dcc0c, stackdata=0xb04dcba8) at threads.c:6008:3
    frame mono#12: 0x003df287 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop(domain=0x00000000, dummy=0xb04dcc0c) at threads.c:6045:9
    frame mono#13: 0x005034b8 WatchWCSessionAppWatchOSExtension`::xamarin_switch_gchandle(self=0x80762c20, to_weak=false) at runtime.m:1805:2
    frame mono#14: 0x005065c1 WatchWCSessionAppWatchOSExtension`::xamarin_retain_trampoline(self=0x80762c20, sel="retain") at trampolines.m:693:2
    frame mono#15: 0x657ea520 libobjc.A.dylib`objc_retain + 64
    frame mono#16: 0x4b4d9caa WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke + 279
    frame mono#17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame mono#18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88
    frame mono#19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27
    frame mono#20: 0x453c6ebd Foundation`-[NSOperation start] + 835
    frame mono#21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27
    frame mono#22: 0x453cb12e Foundation`__NSOQSchedule_f + 194
    frame mono#23: 0x453cb26e Foundation`____addOperations_block_invoke_4 + 20
    frame mono#24: 0x65de007b libdispatch.dylib`_dispatch_call_block_and_release + 15
    frame mono#25: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#26: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421
    frame mono#27: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818
    frame mono#28: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354
    frame mono#29: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109
    frame mono#30: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208
    frame mono#31: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```

Going further, `info` is about this thread:
```
(lldb) p/x *(int *)(((char *) info->node.key) + 0xa0)
(int) $2 = 0x01243f93
(lldb) thread list
Process 12832 stopped
  thread #1: tid = 0x1243ee1, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_303', queue = 'com.apple.main-thread'
  thread #2: tid = 0x1243ee6, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10
  thread mono#3: tid = 0x1243ee7, 0x65f81aea libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
  thread mono#4: tid = 0x1243ee9, 0x65f7e3d2 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
  thread mono#5: tid = 0x1243eea, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10, name = 'Debugger agent'
  thread mono#6: tid = 0x1243f1d, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.uikit.eventfetch-thread'
  thread mono#8: tid = 0x1243f93, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
* thread mono#9: tid = 0x12443a9, 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
  thread mono#10: tid = 0x1244581, 0x65f7fd32 libsystem_kernel.dylib`__workq_kernreturn + 10
(lldb) thread select 8
* thread mono#8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
    frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10
libsystem_kernel.dylib`mach_msg_trap:
->  0x65f7e396 <+10>: retl
    0x65f7e397 <+11>: nop

libsystem_kernel.dylib`mach_msg_overwrite_trap:
    0x65f7e398 <+0>:  movl   $0xffffffe0, %eax         ; imm = 0xFFFFFFE0
    0x65f7e39d <+5>:  calll  0x65f85f44                ; _sysenter_trap
(lldb) bt
* thread mono#8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
  * frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x65f7e8ff libsystem_kernel.dylib`mach_msg + 47
    frame #2: 0x66079679 libxpc.dylib`_xpc_send_serializer + 104
    frame mono#3: 0x660794da libxpc.dylib`_xpc_pipe_simpleroutine + 80
    frame mono#4: 0x66079852 libxpc.dylib`xpc_pipe_simpleroutine + 43
    frame mono#5: 0x66043a8f libsystem_trace.dylib`___os_activity_stream_reflect_block_invoke_2 + 30
    frame mono#6: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#7: 0x65de3d71 libdispatch.dylib`_dispatch_block_invoke_direct + 257
    frame mono#8: 0x65de3c62 libdispatch.dylib`dispatch_block_perform + 112
    frame mono#9: 0x6604349a libsystem_trace.dylib`_os_activity_stream_reflect + 725
    frame mono#10: 0x6604ef19 libsystem_trace.dylib`_os_log_impl_stream + 468
    frame mono#11: 0x6604e44d libsystem_trace.dylib`_os_log_impl_flatten_and_send + 6410
    frame mono#12: 0x6604cb3b libsystem_trace.dylib`_os_log + 137
    frame mono#13: 0x6604f4aa libsystem_trace.dylib`_os_log_impl + 31
    frame mono#14: 0x4b4eb4e9 WatchConnectivity`WCSerializePayloadDictionary + 393
    frame mono#15: 0x4b4d7c4d WatchConnectivity`-[WCSession onqueue_sendResponseDictionary:identifier:] + 195
    frame mono#16: 0x4b4da435 WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke.411 + 35
    frame mono#17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame mono#18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88
    frame mono#19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27
    frame mono#20: 0x453c6ebd Foundation`-[NSOperation start] + 835
    frame mono#21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27
    frame mono#22: 0x453cb12e Foundation`__NSOQSchedule_f + 194
    frame mono#23: 0x453cb067 Foundation`____addOperations_block_invoke_2 + 20
    frame mono#24: 0x65dedf49 libdispatch.dylib`_dispatch_block_async_invoke2 + 77
    frame mono#25: 0x65de4461 libdispatch.dylib`_dispatch_block_async_invoke_and_release + 17
    frame mono#26: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#27: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421
    frame mono#28: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818
    frame mono#29: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354
    frame mono#30: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109
    frame mono#31: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208
    frame mono#32: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```
which is a thread in a "light" detach state (aka. coop detach), where we only unset the domain:
https://github.com/mono/mono/blob/4cefdcb7ce2d939ee78fb45d1b4913eb3bc064fd/mono/metadata/threads.c#L6084-L6111

Fixes mono#17926
lewurm added a commit that referenced this issue Dec 11, 2019
When the debugger tries to suspend all the VM threads, it can happen with cooperative-suspend that it tries to suspend a thread that has previously been attached, but then did a "light" detach (that only unsets the domain). With the domain set to `NULL`, looking up a JitInfo for a given `ip` will result into a crash, but it isn't even necessarily needed for the purpose of suspending a thread.

More details: Consider the following:
```
(lldb) c
error: Process is running.  Use 'process interrupt' to pause execution.
Process 12832 stopped
* thread mono#9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
    frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6
   2713         MonoDomain *domain = (MonoDomain *) mono_thread_info_get_suspend_state (info)->unwind_data [MONO_UNWIND_DATA_DOMAIN];
   2714         if (!domain) {
   2715                 /* not attached */
-> 2716                 ji = NULL;
   2717         } else {
   2718                 ji = mono_jit_info_table_find_internal ( domain, MONO_CONTEXT_GET_IP (&mono_thread_info_get_suspend_state (info)->ctx), TRUE, TRUE);
   2719         }
Target 0: (WatchWCSessionAppWatchOSExtension) stopped.
(lldb) bt
* thread mono#9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
  * frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6
    frame #1: 0x004e177b WatchWCSessionAppWatchOSExtension`mono_thread_info_safe_suspend_and_run(id=0xb0767000, interrupt_kernel=0, callback=(WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical at debugger-agent.c:2708), user_data=0xb04dc718) at mono-threads.c:1358:19
    frame #2: 0x00222799 WatchWCSessionAppWatchOSExtension`notify_thread(key=0x03994508, value=0x81378c00, user_data=0x00000000) at debugger-agent.c:2747:2
    frame mono#3: 0x00355bd8 WatchWCSessionAppWatchOSExtension`mono_g_hash_table_foreach(hash=0x8007b4e0, func=(WatchWCSessionAppWatchOSExtension`notify_thread at debugger-agent.c:2733), user_data=0x00000000) at mono-hash.c:310:4
    frame mono#4: 0x0021e955 WatchWCSessionAppWatchOSExtension`suspend_vm at debugger-agent.c:2844:3
    frame mono#5: 0x00225ff0 WatchWCSessionAppWatchOSExtension`process_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0, il_offset=0, ctx=0x00000000, events=0x805b28e0, suspend_policy=2) at debugger-agent.c:4012:3
    frame mono#6: 0x00227c7c WatchWCSessionAppWatchOSExtension`process_profiler_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0) at debugger-agent.c:4072:2
    frame mono#7: 0x0021b174 WatchWCSessionAppWatchOSExtension`thread_startup(prof=0x00000000, tid=2957889536) at debugger-agent.c:4149:2
    frame mono#8: 0x0037912d WatchWCSessionAppWatchOSExtension`mono_profiler_raise_thread_started(tid=2957889536) at profiler-events.h:103:1
    frame mono#9: 0x003d53da WatchWCSessionAppWatchOSExtension`fire_attach_profiler_events(tid=0xb04dd000) at threads.c:1120:2
    frame mono#10: 0x003d4d83 WatchWCSessionAppWatchOSExtension`mono_thread_attach(domain=0x801750a0) at threads.c:1547:2
    frame mono#11: 0x003df1a1 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop_internal(domain=0x801750a0, cookie=0xb04dcc0c, stackdata=0xb04dcba8) at threads.c:6008:3
    frame mono#12: 0x003df287 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop(domain=0x00000000, dummy=0xb04dcc0c) at threads.c:6045:9
    frame mono#13: 0x005034b8 WatchWCSessionAppWatchOSExtension`::xamarin_switch_gchandle(self=0x80762c20, to_weak=false) at runtime.m:1805:2
    frame mono#14: 0x005065c1 WatchWCSessionAppWatchOSExtension`::xamarin_retain_trampoline(self=0x80762c20, sel="retain") at trampolines.m:693:2
    frame mono#15: 0x657ea520 libobjc.A.dylib`objc_retain + 64
    frame mono#16: 0x4b4d9caa WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke + 279
    frame mono#17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame mono#18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88
    frame mono#19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27
    frame mono#20: 0x453c6ebd Foundation`-[NSOperation start] + 835
    frame mono#21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27
    frame mono#22: 0x453cb12e Foundation`__NSOQSchedule_f + 194
    frame mono#23: 0x453cb26e Foundation`____addOperations_block_invoke_4 + 20
    frame mono#24: 0x65de007b libdispatch.dylib`_dispatch_call_block_and_release + 15
    frame mono#25: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#26: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421
    frame mono#27: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818
    frame mono#28: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354
    frame mono#29: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109
    frame mono#30: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208
    frame mono#31: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```

Going further, `info` is about this thread:
```
(lldb) p/x *(int *)(((char *) info->node.key) + 0xa0)
(int) $2 = 0x01243f93
(lldb) thread list
Process 12832 stopped
  thread #1: tid = 0x1243ee1, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_303', queue = 'com.apple.main-thread'
  thread #2: tid = 0x1243ee6, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10
  thread mono#3: tid = 0x1243ee7, 0x65f81aea libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
  thread mono#4: tid = 0x1243ee9, 0x65f7e3d2 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
  thread mono#5: tid = 0x1243eea, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10, name = 'Debugger agent'
  thread mono#6: tid = 0x1243f1d, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.uikit.eventfetch-thread'
  thread mono#8: tid = 0x1243f93, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
* thread mono#9: tid = 0x12443a9, 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
  thread mono#10: tid = 0x1244581, 0x65f7fd32 libsystem_kernel.dylib`__workq_kernreturn + 10
(lldb) thread select 8
* thread mono#8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
    frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10
libsystem_kernel.dylib`mach_msg_trap:
->  0x65f7e396 <+10>: retl
    0x65f7e397 <+11>: nop

libsystem_kernel.dylib`mach_msg_overwrite_trap:
    0x65f7e398 <+0>:  movl   $0xffffffe0, %eax         ; imm = 0xFFFFFFE0
    0x65f7e39d <+5>:  calll  0x65f85f44                ; _sysenter_trap
(lldb) bt
* thread mono#8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
  * frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x65f7e8ff libsystem_kernel.dylib`mach_msg + 47
    frame #2: 0x66079679 libxpc.dylib`_xpc_send_serializer + 104
    frame mono#3: 0x660794da libxpc.dylib`_xpc_pipe_simpleroutine + 80
    frame mono#4: 0x66079852 libxpc.dylib`xpc_pipe_simpleroutine + 43
    frame mono#5: 0x66043a8f libsystem_trace.dylib`___os_activity_stream_reflect_block_invoke_2 + 30
    frame mono#6: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#7: 0x65de3d71 libdispatch.dylib`_dispatch_block_invoke_direct + 257
    frame mono#8: 0x65de3c62 libdispatch.dylib`dispatch_block_perform + 112
    frame mono#9: 0x6604349a libsystem_trace.dylib`_os_activity_stream_reflect + 725
    frame mono#10: 0x6604ef19 libsystem_trace.dylib`_os_log_impl_stream + 468
    frame mono#11: 0x6604e44d libsystem_trace.dylib`_os_log_impl_flatten_and_send + 6410
    frame mono#12: 0x6604cb3b libsystem_trace.dylib`_os_log + 137
    frame mono#13: 0x6604f4aa libsystem_trace.dylib`_os_log_impl + 31
    frame mono#14: 0x4b4eb4e9 WatchConnectivity`WCSerializePayloadDictionary + 393
    frame mono#15: 0x4b4d7c4d WatchConnectivity`-[WCSession onqueue_sendResponseDictionary:identifier:] + 195
    frame mono#16: 0x4b4da435 WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke.411 + 35
    frame mono#17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame mono#18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88
    frame mono#19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27
    frame mono#20: 0x453c6ebd Foundation`-[NSOperation start] + 835
    frame mono#21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27
    frame mono#22: 0x453cb12e Foundation`__NSOQSchedule_f + 194
    frame mono#23: 0x453cb067 Foundation`____addOperations_block_invoke_2 + 20
    frame mono#24: 0x65dedf49 libdispatch.dylib`_dispatch_block_async_invoke2 + 77
    frame mono#25: 0x65de4461 libdispatch.dylib`_dispatch_block_async_invoke_and_release + 17
    frame mono#26: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#27: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421
    frame mono#28: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818
    frame mono#29: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354
    frame mono#30: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109
    frame mono#31: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208
    frame mono#32: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```
which is a thread in a "light" detach state (aka. coop detach), where we only unset the domain:
https://github.com/mono/mono/blob/4cefdcb7ce2d939ee78fb45d1b4913eb3bc064fd/mono/metadata/threads.c#L6084-L6111

Fixes mono#17926
lewurm pushed a commit that referenced this issue Jan 8, 2020
[2019-12] [debugger] skip suspend for unattached threads

When the debugger tries to suspend all the VM threads, it can happen with cooperative-suspend that it tries to suspend a thread that has previously been attached, but then did a "light" detach (that only unsets the domain). With the domain set to `NULL`, looking up a JitInfo for a given `ip` will result into a crash, but it isn't even necessarily needed for the purpose of suspending a thread.

More details: Consider the following:
```
(lldb) c
error: Process is running.  Use 'process interrupt' to pause execution.
Process 12832 stopped
* thread mono#9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
    frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6
   2713         MonoDomain *domain = (MonoDomain *) mono_thread_info_get_suspend_state (info)->unwind_data [MONO_UNWIND_DATA_DOMAIN];
   2714         if (!domain) {
   2715                 /* not attached */
-> 2716                 ji = NULL;
   2717         } else {
   2718                 ji = mono_jit_info_table_find_internal ( domain, MONO_CONTEXT_GET_IP (&mono_thread_info_get_suspend_state (info)->ctx), TRUE, TRUE);
   2719         }
Target 0: (WatchWCSessionAppWatchOSExtension) stopped.
(lldb) bt
* thread mono#9, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
  * frame #0: 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6
    frame #1: 0x004e177b WatchWCSessionAppWatchOSExtension`mono_thread_info_safe_suspend_and_run(id=0xb0767000, interrupt_kernel=0, callback=(WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical at debugger-agent.c:2708), user_data=0xb04dc718) at mono-threads.c:1358:19
    frame #2: 0x00222799 WatchWCSessionAppWatchOSExtension`notify_thread(key=0x03994508, value=0x81378c00, user_data=0x00000000) at debugger-agent.c:2747:2
    frame mono#3: 0x00355bd8 WatchWCSessionAppWatchOSExtension`mono_g_hash_table_foreach(hash=0x8007b4e0, func=(WatchWCSessionAppWatchOSExtension`notify_thread at debugger-agent.c:2733), user_data=0x00000000) at mono-hash.c:310:4
    frame mono#4: 0x0021e955 WatchWCSessionAppWatchOSExtension`suspend_vm at debugger-agent.c:2844:3
    frame mono#5: 0x00225ff0 WatchWCSessionAppWatchOSExtension`process_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0, il_offset=0, ctx=0x00000000, events=0x805b28e0, suspend_policy=2) at debugger-agent.c:4012:3
    frame mono#6: 0x00227c7c WatchWCSessionAppWatchOSExtension`process_profiler_event(event=EVENT_KIND_THREAD_START, arg=0x039945d0) at debugger-agent.c:4072:2
    frame mono#7: 0x0021b174 WatchWCSessionAppWatchOSExtension`thread_startup(prof=0x00000000, tid=2957889536) at debugger-agent.c:4149:2
    frame mono#8: 0x0037912d WatchWCSessionAppWatchOSExtension`mono_profiler_raise_thread_started(tid=2957889536) at profiler-events.h:103:1
    frame mono#9: 0x003d53da WatchWCSessionAppWatchOSExtension`fire_attach_profiler_events(tid=0xb04dd000) at threads.c:1120:2
    frame mono#10: 0x003d4d83 WatchWCSessionAppWatchOSExtension`mono_thread_attach(domain=0x801750a0) at threads.c:1547:2
    frame mono#11: 0x003df1a1 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop_internal(domain=0x801750a0, cookie=0xb04dcc0c, stackdata=0xb04dcba8) at threads.c:6008:3
    frame mono#12: 0x003df287 WatchWCSessionAppWatchOSExtension`mono_threads_attach_coop(domain=0x00000000, dummy=0xb04dcc0c) at threads.c:6045:9
    frame mono#13: 0x005034b8 WatchWCSessionAppWatchOSExtension`::xamarin_switch_gchandle(self=0x80762c20, to_weak=false) at runtime.m:1805:2
    frame mono#14: 0x005065c1 WatchWCSessionAppWatchOSExtension`::xamarin_retain_trampoline(self=0x80762c20, sel="retain") at trampolines.m:693:2
    frame mono#15: 0x657ea520 libobjc.A.dylib`objc_retain + 64
    frame mono#16: 0x4b4d9caa WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke + 279
    frame mono#17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame mono#18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88
    frame mono#19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27
    frame mono#20: 0x453c6ebd Foundation`-[NSOperation start] + 835
    frame mono#21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27
    frame mono#22: 0x453cb12e Foundation`__NSOQSchedule_f + 194
    frame mono#23: 0x453cb26e Foundation`____addOperations_block_invoke_4 + 20
    frame mono#24: 0x65de007b libdispatch.dylib`_dispatch_call_block_and_release + 15
    frame mono#25: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#26: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421
    frame mono#27: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818
    frame mono#28: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354
    frame mono#29: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109
    frame mono#30: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208
    frame mono#31: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```

Going further, `info` is about this thread:
```
(lldb) p/x *(int *)(((char *) info->node.key) + 0xa0)
(int) $2 = 0x01243f93
(lldb) thread list
Process 12832 stopped
  thread #1: tid = 0x1243ee1, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_303', queue = 'com.apple.main-thread'
  thread #2: tid = 0x1243ee6, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10
  thread mono#3: tid = 0x1243ee7, 0x65f81aea libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
  thread mono#4: tid = 0x1243ee9, 0x65f7e3d2 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
  thread mono#5: tid = 0x1243eea, 0x65f816e2 libsystem_kernel.dylib`__recvfrom + 10, name = 'Debugger agent'
  thread mono#6: tid = 0x1243f1d, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'com.apple.uikit.eventfetch-thread'
  thread mono#8: tid = 0x1243f93, 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
* thread mono#9: tid = 0x12443a9, 0x00222870 WatchWCSessionAppWatchOSExtension`debugger_interrupt_critical(info=0x81365400, user_data=0xb04dc718) at debugger-agent.c:2716:6, name = 'tid_a31f', queue = 'NSOperationQueue 0x8069b670 (QOS: UTILITY)', stop reason = breakpoint 1.1
  thread mono#10: tid = 0x1244581, 0x65f7fd32 libsystem_kernel.dylib`__workq_kernreturn + 10
(lldb) thread select 8
* thread mono#8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
    frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10
libsystem_kernel.dylib`mach_msg_trap:
->  0x65f7e396 <+10>: retl
    0x65f7e397 <+11>: nop

libsystem_kernel.dylib`mach_msg_overwrite_trap:
    0x65f7e398 <+0>:  movl   $0xffffffe0, %eax         ; imm = 0xFFFFFFE0
    0x65f7e39d <+5>:  calll  0x65f85f44                ; _sysenter_trap
(lldb) bt
* thread mono#8, name = 'tid_6d0f', queue = 'NSOperationQueue 0x8069b300 (QOS: UTILITY)'
  * frame #0: 0x65f7e396 libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x65f7e8ff libsystem_kernel.dylib`mach_msg + 47
    frame #2: 0x66079679 libxpc.dylib`_xpc_send_serializer + 104
    frame mono#3: 0x660794da libxpc.dylib`_xpc_pipe_simpleroutine + 80
    frame mono#4: 0x66079852 libxpc.dylib`xpc_pipe_simpleroutine + 43
    frame mono#5: 0x66043a8f libsystem_trace.dylib`___os_activity_stream_reflect_block_invoke_2 + 30
    frame mono#6: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#7: 0x65de3d71 libdispatch.dylib`_dispatch_block_invoke_direct + 257
    frame mono#8: 0x65de3c62 libdispatch.dylib`dispatch_block_perform + 112
    frame mono#9: 0x6604349a libsystem_trace.dylib`_os_activity_stream_reflect + 725
    frame mono#10: 0x6604ef19 libsystem_trace.dylib`_os_log_impl_stream + 468
    frame mono#11: 0x6604e44d libsystem_trace.dylib`_os_log_impl_flatten_and_send + 6410
    frame mono#12: 0x6604cb3b libsystem_trace.dylib`_os_log + 137
    frame mono#13: 0x6604f4aa libsystem_trace.dylib`_os_log_impl + 31
    frame mono#14: 0x4b4eb4e9 WatchConnectivity`WCSerializePayloadDictionary + 393
    frame mono#15: 0x4b4d7c4d WatchConnectivity`-[WCSession onqueue_sendResponseDictionary:identifier:] + 195
    frame mono#16: 0x4b4da435 WatchConnectivity`__66-[WCSession onqueue_handleDictionaryMessageRequest:withPairingID:]_block_invoke.411 + 35
    frame mono#17: 0x453c7df7 Foundation`__NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 12
    frame mono#18: 0x453c7cf4 Foundation`-[NSBlockOperation main] + 88
    frame mono#19: 0x453cacee Foundation`__NSOPERATION_IS_INVOKING_MAIN__ + 27
    frame mono#20: 0x453c6ebd Foundation`-[NSOperation start] + 835
    frame mono#21: 0x453cb606 Foundation`__NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ + 27
    frame mono#22: 0x453cb12e Foundation`__NSOQSchedule_f + 194
    frame mono#23: 0x453cb067 Foundation`____addOperations_block_invoke_2 + 20
    frame mono#24: 0x65dedf49 libdispatch.dylib`_dispatch_block_async_invoke2 + 77
    frame mono#25: 0x65de4461 libdispatch.dylib`_dispatch_block_async_invoke_and_release + 17
    frame mono#26: 0x65de126f libdispatch.dylib`_dispatch_client_callout + 14
    frame mono#27: 0x65de3788 libdispatch.dylib`_dispatch_continuation_pop + 421
    frame mono#28: 0x65de2ee3 libdispatch.dylib`_dispatch_async_redirect_invoke + 818
    frame mono#29: 0x65df087d libdispatch.dylib`_dispatch_root_queue_drain + 354
    frame mono#30: 0x65df0ff3 libdispatch.dylib`_dispatch_worker_thread2 + 109
    frame mono#31: 0x66024fa0 libsystem_pthread.dylib`_pthread_wqthread + 208
    frame mono#32: 0x66024e44 libsystem_pthread.dylib`start_wqthread + 36
```
which is a thread in a "light" detach state (aka. coop detach), where we only unset the domain:
https://github.com/mono/mono/blob/4cefdcb7ce2d939ee78fb45d1b4913eb3bc064fd/mono/metadata/threads.c#L6084-L6111

Fixes mono#17926



<!--
Thank you for your Pull Request!

If you are new to contributing to Mono, please try to do your best at conforming to our coding guidelines http://www.mono-project.com/community/contributing/coding-guidelines/ but don't worry if you get something wrong. One of the project members will help you to get things landed.

Does your pull request fix any of the existing issues? Please use the following format: Fixes #issue-number
-->


Backport of mono#18105.

/cc @lewurm
lewurm added a commit that referenced this issue Jan 21, 2020
`jit_tls->interp_context` gets initialized lazily, that is, upon the first interpreter execution on a specific thread (e.g. via interp_runtime_invoke). However, with mixed mode the execution can purely happen in AOT code upon the first interaction with the managed debugger.

Stack trace:

```
  thread #1, name = 'tid_407', queue = 'com.apple.main-thread'
    frame #0: 0x0000000190aedc94 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x0000000190a0f094 libsystem_pthread.dylib`_pthread_cond_wait$VARIANT$armv81 + 672
    frame #2: 0x000000010431318c reloadcontext.iOS`mono_os_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-os-mutex.h:219:8
    frame mono#3: 0x0000000104312a68 reloadcontext.iOS`mono_coop_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-coop-mutex.h:91:2
    frame mono#4: 0x0000000104312858 reloadcontext.iOS`suspend_current at debugger-agent.c:3021:4
    frame mono#5: 0x000000010431be18 reloadcontext.iOS`process_event(event=EVENT_KIND_BREAKPOINT, arg=0x0000000145d09ae8, il_offset=0, ctx=0x0000000149015c20, events=0x0000000000000000, suspend_policy=2) at debugger-agent.c:4058:3
    frame mono#6: 0x0000000104310cf4 reloadcontext.iOS`process_breakpoint_events(_evts=0x000000028351a680, method=0x0000000145d09ae8, ctx=0x0000000149015c20, il_offset=0) at debugger-agent.c:4722:3
    frame mono#7: 0x000000010432f1c8 reloadcontext.iOS`mono_de_process_breakpoint(void_tls=0x0000000149014e00, from_signal=0) at debugger-engine.c:1141:2
    frame mono#8: 0x000000010430f238 reloadcontext.iOS`debugger_agent_breakpoint_from_context(ctx=0x000000016f656790) at debugger-agent.c:4938:2
    frame mono#9: 0x00000001011b73a4 reloadcontext.iOS`sdb_breakpoint_trampoline + 148
    frame mono#10: 0x00000001008511b4 reloadcontext.iOS`reloadcontext_iOS_Application_Main_string__(args=0x000000010703a030) at Main.cs:14
    frame mono#11: 0x00000001010f9730 reloadcontext.iOS`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
    frame mono#12: 0x00000001042fd8b8 reloadcontext.iOS`mono_jit_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at mini-runtime.c:3162:3
    frame mono#13: 0x0000000104411950 reloadcontext.iOS`do_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at object.c:3052:11
    frame mono#14: 0x000000010440c4dc reloadcontext.iOS`mono_runtime_invoke_checked(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, error=0x000000016f656ff8) at object.c:3220:9
    frame mono#15: 0x0000000104415ae0 reloadcontext.iOS`do_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5184:3
    frame mono#16: 0x00000001044144ac reloadcontext.iOS`mono_runtime_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5281:9
    frame mono#17: 0x0000000104414500 reloadcontext.iOS`mono_runtime_run_main_checked(method=0x0000000145d09ae8, argc=1, argv=0x000000016f6570d0, error=0x000000016f656ff8) at object.c:4734:9
    frame mono#18: 0x00000001042d3b54 reloadcontext.iOS`mono_jit_exec_internal(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1320:13
    frame mono#19: 0x00000001042d39a4 reloadcontext.iOS`mono_jit_exec(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1265:7
    frame mono#20: 0x0000000104597994 reloadcontext.iOS`::xamarin_main(argc=5, argv=0x000000016f657a80, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:483:8
    frame mono#21: 0x00000001008510dc reloadcontext.iOS`main(argc=5, argv=0x000000016f657a80) at main.m:104:11
    frame mono#22: 0x0000000190af8360 libdyld.dylib`start + 4
[...]
* thread mono#5, name = 'Debugger agent', stop reason = signal SIGABRT
  * frame #0: 0x0000000190aedec4 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000190a0d724 libsystem_pthread.dylib`pthread_kill$VARIANT$armv81 + 216
    frame #2: 0x000000019095d844 libsystem_c.dylib`abort + 100
    frame mono#3: 0x00000001045871b4 reloadcontext.iOS`log_callback(log_domain=0x0000000000000000, log_level="error", message="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n", fatal=4, user_data=0x0000000000000000) at runtime.m:1213:3
    frame mono#4: 0x0000000104544fc8 reloadcontext.iOS`eglib_log_adapter(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, message="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n", user_data=0x0000000000000000) at mono-logger.c:405:2
    frame mono#5: 0x000000010456093c reloadcontext.iOS`monoeg_g_logstr(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, msg="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n") at goutput.c:134:2
    frame mono#6: 0x0000000104560598 reloadcontext.iOS`monoeg_g_logv_nofree(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="* Assertion at %s:%d, condition `%s' not met\n", args="e\x12z\x04\x01") at goutput.c:149:2
    frame mono#7: 0x000000010456061c reloadcontext.iOS`monoeg_assertion_message(format="* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:184:22
    frame mono#8: 0x0000000104560674 reloadcontext.iOS`mono_assertion_message(file="../../../../../mono/mini/interp/interp.c", line=7176, condition="context") at goutput.c:203:2
    frame mono#9: 0x000000010459b570 reloadcontext.iOS`interp_get_resume_state(jit_tls=0x000000014900d000, has_resume_state=0x000000016fc7a9f4, interp_frame=0x000000016fc7a9e8, handler_ip=0x000000016fc7a9e0) at interp.c:7176:2
    frame mono#10: 0x0000000104319420 reloadcontext.iOS`compute_frame_info(thread=0x0000000104fe4130, tls=0x0000000149014e00, force_update=1) at debugger-agent.c:3422:3
    frame mono#11: 0x0000000104320d40 reloadcontext.iOS`thread_commands(command=1, p="", end="", buf=0x000000016fc7acf8) at debugger-agent.c:9048:3
    frame mono#12: 0x000000010431cca0 reloadcontext.iOS`debugger_thread(arg=0x0000000000000000) at debugger-agent.c:10132:10
    frame mono#13: 0x000000010447eb04 reloadcontext.iOS`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000000016fc7b000) at threads.c:1232:3
    frame mono#14: 0x000000010447e788 reloadcontext.iOS`start_wrapper(data=0x000000028203ef40) at threads.c:1305:8
    frame mono#15: 0x0000000190a11d8c libsystem_pthread.dylib`_pthread_start + 15
[...]
```

Thanks to @drasticactions for helping me to reproduce.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1050615
lewurm added a commit that referenced this issue Jan 21, 2020
`jit_tls->interp_context` gets initialized lazily, that is, upon the first interpreter execution on a specific thread (e.g. via interp_runtime_invoke). However, with mixed mode the execution can purely happen in AOT code upon the first interaction with the managed debugger.

Stack trace:

```
  thread #1, name = 'tid_407', queue = 'com.apple.main-thread'
    frame #0: 0x0000000190aedc94 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x0000000190a0f094 libsystem_pthread.dylib`_pthread_cond_wait$VARIANT$armv81 + 672
    frame #2: 0x000000010431318c reloadcontext.iOS`mono_os_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-os-mutex.h:219:8
    frame mono#3: 0x0000000104312a68 reloadcontext.iOS`mono_coop_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-coop-mutex.h:91:2
    frame mono#4: 0x0000000104312858 reloadcontext.iOS`suspend_current at debugger-agent.c:3021:4
    frame mono#5: 0x000000010431be18 reloadcontext.iOS`process_event(event=EVENT_KIND_BREAKPOINT, arg=0x0000000145d09ae8, il_offset=0, ctx=0x0000000149015c20, events=0x0000000000000000, suspend_policy=2) at debugger-agent.c:4058:3
    frame mono#6: 0x0000000104310cf4 reloadcontext.iOS`process_breakpoint_events(_evts=0x000000028351a680, method=0x0000000145d09ae8, ctx=0x0000000149015c20, il_offset=0) at debugger-agent.c:4722:3
    frame mono#7: 0x000000010432f1c8 reloadcontext.iOS`mono_de_process_breakpoint(void_tls=0x0000000149014e00, from_signal=0) at debugger-engine.c:1141:2
    frame mono#8: 0x000000010430f238 reloadcontext.iOS`debugger_agent_breakpoint_from_context(ctx=0x000000016f656790) at debugger-agent.c:4938:2
    frame mono#9: 0x00000001011b73a4 reloadcontext.iOS`sdb_breakpoint_trampoline + 148
    frame mono#10: 0x00000001008511b4 reloadcontext.iOS`reloadcontext_iOS_Application_Main_string__(args=0x000000010703a030) at Main.cs:14
    frame mono#11: 0x00000001010f9730 reloadcontext.iOS`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
    frame mono#12: 0x00000001042fd8b8 reloadcontext.iOS`mono_jit_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at mini-runtime.c:3162:3
    frame mono#13: 0x0000000104411950 reloadcontext.iOS`do_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at object.c:3052:11
    frame mono#14: 0x000000010440c4dc reloadcontext.iOS`mono_runtime_invoke_checked(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, error=0x000000016f656ff8) at object.c:3220:9
    frame mono#15: 0x0000000104415ae0 reloadcontext.iOS`do_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5184:3
    frame mono#16: 0x00000001044144ac reloadcontext.iOS`mono_runtime_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5281:9
    frame mono#17: 0x0000000104414500 reloadcontext.iOS`mono_runtime_run_main_checked(method=0x0000000145d09ae8, argc=1, argv=0x000000016f6570d0, error=0x000000016f656ff8) at object.c:4734:9
    frame mono#18: 0x00000001042d3b54 reloadcontext.iOS`mono_jit_exec_internal(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1320:13
    frame mono#19: 0x00000001042d39a4 reloadcontext.iOS`mono_jit_exec(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1265:7
    frame mono#20: 0x0000000104597994 reloadcontext.iOS`::xamarin_main(argc=5, argv=0x000000016f657a80, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:483:8
    frame mono#21: 0x00000001008510dc reloadcontext.iOS`main(argc=5, argv=0x000000016f657a80) at main.m:104:11
    frame mono#22: 0x0000000190af8360 libdyld.dylib`start + 4
[...]
* thread mono#5, name = 'Debugger agent', stop reason = signal SIGABRT
  * frame #0: 0x0000000190aedec4 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000190a0d724 libsystem_pthread.dylib`pthread_kill$VARIANT$armv81 + 216
    frame #2: 0x000000019095d844 libsystem_c.dylib`abort + 100
    frame mono#3: 0x00000001045871b4 reloadcontext.iOS`log_callback(log_domain=0x0000000000000000, log_level="error", message="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n", fatal=4, user_data=0x0000000000000000) at runtime.m:1213:3
    frame mono#4: 0x0000000104544fc8 reloadcontext.iOS`eglib_log_adapter(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, message="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n", user_data=0x0000000000000000) at mono-logger.c:405:2
    frame mono#5: 0x000000010456093c reloadcontext.iOS`monoeg_g_logstr(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, msg="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n") at goutput.c:134:2
    frame mono#6: 0x0000000104560598 reloadcontext.iOS`monoeg_g_logv_nofree(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="* Assertion at %s:%d, condition `%s' not met\n", args="e\x12z\x04\x01") at goutput.c:149:2
    frame mono#7: 0x000000010456061c reloadcontext.iOS`monoeg_assertion_message(format="* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:184:22
    frame mono#8: 0x0000000104560674 reloadcontext.iOS`mono_assertion_message(file="../../../../../mono/mini/interp/interp.c", line=7176, condition="context") at goutput.c:203:2
    frame mono#9: 0x000000010459b570 reloadcontext.iOS`interp_get_resume_state(jit_tls=0x000000014900d000, has_resume_state=0x000000016fc7a9f4, interp_frame=0x000000016fc7a9e8, handler_ip=0x000000016fc7a9e0) at interp.c:7176:2
    frame mono#10: 0x0000000104319420 reloadcontext.iOS`compute_frame_info(thread=0x0000000104fe4130, tls=0x0000000149014e00, force_update=1) at debugger-agent.c:3422:3
    frame mono#11: 0x0000000104320d40 reloadcontext.iOS`thread_commands(command=1, p="", end="", buf=0x000000016fc7acf8) at debugger-agent.c:9048:3
    frame mono#12: 0x000000010431cca0 reloadcontext.iOS`debugger_thread(arg=0x0000000000000000) at debugger-agent.c:10132:10
    frame mono#13: 0x000000010447eb04 reloadcontext.iOS`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000000016fc7b000) at threads.c:1232:3
    frame mono#14: 0x000000010447e788 reloadcontext.iOS`start_wrapper(data=0x000000028203ef40) at threads.c:1305:8
    frame mono#15: 0x0000000190a11d8c libsystem_pthread.dylib`_pthread_start + 15
[...]
```

Thanks to @drasticactions for helping me to reproduce.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1050615
lewurm added a commit that referenced this issue Jan 29, 2020
…ono#18533)

`jit_tls->interp_context` gets initialized lazily, that is, upon the first interpreter execution on a specific thread (e.g. via interp_runtime_invoke). However, with mixed mode the execution can purely happen in AOT code upon the first interaction with the managed debugger.

Stack trace:

```
  thread #1, name = 'tid_407', queue = 'com.apple.main-thread'
    frame #0: 0x0000000190aedc94 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame #1: 0x0000000190a0f094 libsystem_pthread.dylib`_pthread_cond_wait$VARIANT$armv81 + 672
    frame #2: 0x000000010431318c reloadcontext.iOS`mono_os_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-os-mutex.h:219:8
    frame mono#3: 0x0000000104312a68 reloadcontext.iOS`mono_coop_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-coop-mutex.h:91:2
    frame mono#4: 0x0000000104312858 reloadcontext.iOS`suspend_current at debugger-agent.c:3021:4
    frame mono#5: 0x000000010431be18 reloadcontext.iOS`process_event(event=EVENT_KIND_BREAKPOINT, arg=0x0000000145d09ae8, il_offset=0, ctx=0x0000000149015c20, events=0x0000000000000000, suspend_policy=2) at debugger-agent.c:4058:3
    frame mono#6: 0x0000000104310cf4 reloadcontext.iOS`process_breakpoint_events(_evts=0x000000028351a680, method=0x0000000145d09ae8, ctx=0x0000000149015c20, il_offset=0) at debugger-agent.c:4722:3
    frame mono#7: 0x000000010432f1c8 reloadcontext.iOS`mono_de_process_breakpoint(void_tls=0x0000000149014e00, from_signal=0) at debugger-engine.c:1141:2
    frame mono#8: 0x000000010430f238 reloadcontext.iOS`debugger_agent_breakpoint_from_context(ctx=0x000000016f656790) at debugger-agent.c:4938:2
    frame mono#9: 0x00000001011b73a4 reloadcontext.iOS`sdb_breakpoint_trampoline + 148
    frame mono#10: 0x00000001008511b4 reloadcontext.iOS`reloadcontext_iOS_Application_Main_string__(args=0x000000010703a030) at Main.cs:14
    frame mono#11: 0x00000001010f9730 reloadcontext.iOS`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
    frame mono#12: 0x00000001042fd8b8 reloadcontext.iOS`mono_jit_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at mini-runtime.c:3162:3
    frame mono#13: 0x0000000104411950 reloadcontext.iOS`do_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at object.c:3052:11
    frame mono#14: 0x000000010440c4dc reloadcontext.iOS`mono_runtime_invoke_checked(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, error=0x000000016f656ff8) at object.c:3220:9
    frame mono#15: 0x0000000104415ae0 reloadcontext.iOS`do_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5184:3
    frame mono#16: 0x00000001044144ac reloadcontext.iOS`mono_runtime_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5281:9
    frame mono#17: 0x0000000104414500 reloadcontext.iOS`mono_runtime_run_main_checked(method=0x0000000145d09ae8, argc=1, argv=0x000000016f6570d0, error=0x000000016f656ff8) at object.c:4734:9
    frame mono#18: 0x00000001042d3b54 reloadcontext.iOS`mono_jit_exec_internal(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1320:13
    frame mono#19: 0x00000001042d39a4 reloadcontext.iOS`mono_jit_exec(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1265:7
    frame mono#20: 0x0000000104597994 reloadcontext.iOS`::xamarin_main(argc=5, argv=0x000000016f657a80, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:483:8
    frame mono#21: 0x00000001008510dc reloadcontext.iOS`main(argc=5, argv=0x000000016f657a80) at main.m:104:11
    frame mono#22: 0x0000000190af8360 libdyld.dylib`start + 4
[...]
* thread mono#5, name = 'Debugger agent', stop reason = signal SIGABRT
  * frame #0: 0x0000000190aedec4 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x0000000190a0d724 libsystem_pthread.dylib`pthread_kill$VARIANT$armv81 + 216
    frame #2: 0x000000019095d844 libsystem_c.dylib`abort + 100
    frame mono#3: 0x00000001045871b4 reloadcontext.iOS`log_callback(log_domain=0x0000000000000000, log_level="error", message="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n", fatal=4, user_data=0x0000000000000000) at runtime.m:1213:3
    frame mono#4: 0x0000000104544fc8 reloadcontext.iOS`eglib_log_adapter(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, message="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n", user_data=0x0000000000000000) at mono-logger.c:405:2
    frame mono#5: 0x000000010456093c reloadcontext.iOS`monoeg_g_logstr(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, msg="* Assertion at ../../../../../mono/mini/interp/interp.c:7176, condition `context' not met\n") at goutput.c:134:2
    frame mono#6: 0x0000000104560598 reloadcontext.iOS`monoeg_g_logv_nofree(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="* Assertion at %s:%d, condition `%s' not met\n", args="e\x12z\x04\x01") at goutput.c:149:2
    frame mono#7: 0x000000010456061c reloadcontext.iOS`monoeg_assertion_message(format="* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:184:22
    frame mono#8: 0x0000000104560674 reloadcontext.iOS`mono_assertion_message(file="../../../../../mono/mini/interp/interp.c", line=7176, condition="context") at goutput.c:203:2
    frame mono#9: 0x000000010459b570 reloadcontext.iOS`interp_get_resume_state(jit_tls=0x000000014900d000, has_resume_state=0x000000016fc7a9f4, interp_frame=0x000000016fc7a9e8, handler_ip=0x000000016fc7a9e0) at interp.c:7176:2
    frame mono#10: 0x0000000104319420 reloadcontext.iOS`compute_frame_info(thread=0x0000000104fe4130, tls=0x0000000149014e00, force_update=1) at debugger-agent.c:3422:3
    frame mono#11: 0x0000000104320d40 reloadcontext.iOS`thread_commands(command=1, p="", end="", buf=0x000000016fc7acf8) at debugger-agent.c:9048:3
    frame mono#12: 0x000000010431cca0 reloadcontext.iOS`debugger_thread(arg=0x0000000000000000) at debugger-agent.c:10132:10
    frame mono#13: 0x000000010447eb04 reloadcontext.iOS`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000000016fc7b000) at threads.c:1232:3
    frame mono#14: 0x000000010447e788 reloadcontext.iOS`start_wrapper(data=0x000000028203ef40) at threads.c:1305:8
    frame mono#15: 0x0000000190a11d8c libsystem_pthread.dylib`_pthread_start + 15
[...]
```

Thanks to @drasticactions for helping me to reproduce.

Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1050615
lewurm pushed a commit that referenced this issue Jul 27, 2020
…ono#19839)

`Xamarin.Android` native runtime calls `mono_reflection_type_from_name`
and passes `NULL` as the `image` parameter.  The parameter is then
propagated all the way to `_mono_reflection_get_type_from_info` where,
in case the assembly isn't loaded yet, it is used to obtain base
directory of the assembly.  However, since the `image` parameter is
`NULL` in our case, attempt to dereference it causes a segfault:

    libc    : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0 in tid 11029 (ompanyname.app3), pid 11029 (ompanyname.app3)
    crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
    /system/bin/tombstoned: received crash request for pid 11029
    crash_dump64: performing dump of process 11029 (target tid = 11029)
    DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
    DEBUG   : Build fingerprint: 'google/sdk_gphone_x86_64/generic_x86_64:10/QSR1.190920.001/5891938:user/release-keys'
    DEBUG   : Revision: '0'
    DEBUG   : ABI: 'x86_64'
    DEBUG   : Timestamp: 2020-05-25 14:45:29+0200
    DEBUG   : pid: 11029, tid: 11029, name: ompanyname.app3  >>> com.companyname.app3 <<<
    DEBUG   : uid: 10134
    DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x4c0
    DEBUG   : Cause: null pointer dereference
    DEBUG   :     rax 000000000000002f  rbx 0000000000000001  rcx 0000000000000000  rdx 0000000000000030
    DEBUG   :     r8  0000000000000003  r9  000000000013e2e2  r10 0173eed800000000  r11 0000000000000206
    DEBUG   :     r12 0000000000000000  r13 00007478530343c0  r14 00007478075eda33  r15 000074780763efb0
    DEBUG   :     rdi 0000000000000000  rsi 00007478e2cb14d0
    DEBUG   :     rbp 00007ffef3a35680  rsp 00007ffef3a355d0  rip 0000747807a4066a
    DEBUG   :
    DEBUG   : backtrace:
    DEBUG   :       #00 pc 00000000003ba66a  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (_mono_reflection_get_type_from_info+474)
    DEBUG   :       #1 pc 00000000003ba3d1  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name_checked+321)
    DEBUG   :       #2 pc 00000000003ba26d  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonosgen-2.0.so (mono_reflection_type_from_name+125)
    DEBUG   :       mono#3 pc 000000000000ddb5  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+389) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
    DEBUG   :       mono#4 pc 000000000000def3  /data/app/com.companyname.app3-aQUF6Ge6_v-WaLb5i8Q7vw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99) (BuildId: 9952f1cfe0d910ae631abc73479f88eef34fd71d)
    DEBUG   :       mono#5 pc 0000000000069532  <anonymous:5ad25000>

Even though this happens in `Xamarin.Android`, the error may occur for
any embedding application which passes `NULL` for the `image` parameter
in situation when the assembly isn't in memory yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant