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.

Sign up for GitHub

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

Jump to bottom

Please pull 250e8b93bfbfdd24d78413aac2478c8f2c39d3c1 #1

Merged
0 commits merged into from Oct 25, 2010
Merged

Please pull 250e8b93bfbfdd24d78413aac2478c8f2c39d3c1 #1

0 commits merged into from Oct 25, 2010

Conversation

rnagy
Copy link
Contributor

@rnagy rnagy commented Sep 15, 2010

Hi

Please pull 250e8b93bfbfdd24d78413aac2478c8f2c39d3c1 that fixes some build issues.

dschuff referenced this pull request in dschuff/mono Oct 17, 2011
@dschuff
Merge pull request elijahtaylor#1 from pasko/master
ee48724 
-O2
kumpera pushed a commit that referenced this pull request Jan 10, 2013
Merge pull request #1 from knocte/master
48426d0 
Unbreak API and other nitpicks
@awinters-fvs awinters-fvs mentioned this pull request Mar 2, 2013
Merged
pruiz referenced this pull request Aug 2, 2013
@pruiz
Refactor of Route's GetVirtualPath implementation based on System.Web…
6c70b38 
….Http.Routing code in order to fix a few incompatibilities between our implementation and the one at ms.net
luhenry added a commit that referenced this pull request Oct 7, 2014
@luhenry
[threaddpool] Fix deadlock in thread pool with monitor thread
478f99f 
Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit.

Thread 7 (Thread 0x1c13 of process 99776):
#0  0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103
#2  0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898
#3  0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657
#4  0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704
#5  0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84
#6  0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
#7  0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
#8  0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
#9  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x1503 of process 99776):
#0  0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib
#2  0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595
#3  0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540
#4  0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194
#5  0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516
#6  0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658
#7  0x00000001002c70e5 in mono_thread_manage () at threads.c:2951
#8  0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021
#9  0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91
#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122
luhenry added a commit that referenced this pull request Oct 8, 2014
@luhenry
[threaddpool] Fix deadlock in thread pool with monitor thread (2nd at…
98ce3f7 
…tempt)

Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit.

Thread 7 (Thread 0x1c13 of process 99776):
#0  0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103
#2  0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898
#3  0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657
#4  0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704
#5  0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84
#6  0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
#7  0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
#8  0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
#9  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x1503 of process 99776):
#0  0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib
#1  0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib
#2  0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595
#3  0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540
#4  0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194
#5  0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516
#6  0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658
#7  0x00000001002c70e5 in mono_thread_manage () at threads.c:2951
#8  0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021
#9  0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91
#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122

Thanks @akoeplinger for the help debugging
martinpotter pushed a commit to LogosBible/mono that referenced this pull request Oct 12, 2014
@luhenry @martinpotter
[threaddpool] Fix deadlock in thread pool with monitor thread
d2988e7 
Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit.

Thread 7 (Thread 0x1c13 of process 99776):
#0  0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib
mono#1  0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103
mono#2  0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898
mono#3  0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657
mono#4  0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704
mono#5  0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84
mono#6  0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
mono#7  0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
mono#8  0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
mono#9  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x1503 of process 99776):
#0  0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib
mono#1  0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib
mono#2  0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595
mono#3  0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540
mono#4  0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194
mono#5  0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516
mono#6  0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658
mono#7  0x00000001002c70e5 in mono_thread_manage () at threads.c:2951
mono#8  0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021
mono#9  0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91
mono#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122
luhenry added a commit that referenced this pull request Oct 22, 2014
@luhenry
[threadpool] Fix deadlock/starvation of the thread pool
a142d92 
The issue was with the new heuristic of the thread pool which would not create new threads, leading to deadlock between dependent tasks.
The fix is to check if every worker threads are sleeping, waiting or joining, and if that's the case, then we create a new thread because we might be in the case where the tasks being currently run depends on one still being enqueued in the cq or one of the wsq.

The following tests would previously fail :

1) MonoTests.System.Threading.Tasks.TaskTests.DoubleWaitTest :   #1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.<DoubleWaitTest>m__27 () [0x00077] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:800
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action, Int32 numRun) [0x00007] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:48
at MonoTests.System.Threading.Tasks.TaskTests.DoubleWaitTest () [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:790
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

2) MonoTests.System.Threading.Tasks.TaskTests.HideSchedulerTest :   #1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.HideSchedulerTest () [0x0003d] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:1914
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

3) MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsAfter :   #1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsAfter () [0x00070] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:317
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

4) MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsBefore :   #1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsBefore () [0x00070] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:341
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

5) MonoTests.System.Threading.Tasks.TaskTests.WaitAnyTest :   #3
  Expected: not -1
  But was:  -1

at MonoTests.System.Threading.Tasks.TaskTests.<WaitAnyTest>m__0 () [0x00026] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:142
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action, Int32 numRun) [0x00007] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:48
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action) [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:42
at MonoTests.System.Threading.Tasks.TaskTests.WaitAnyTest () [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:128
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

6) MonoTests.System.Threading.Tasks.TaskTests.WaitChildTestCase :   #0b
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.<WaitChildTestCase>m__25 () [0x0006d] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:705
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action, Int32 numRun) [0x00007] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:48
at MonoTests.System.Threading.Tasks.TaskTests.WaitChildTestCase () [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:684
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

7) MonoTests.System.Threading.Tasks.TaskTests.WaitingForChildrenToComplete :   #3
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.WaitingForChildrenToComplete () [0x00048] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:734
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230
tritao added a commit that referenced this pull request Feb 6, 2015
@tritao
[runtime] Fixed marshalling bug in `mono_marshal_get_native_func_wrap…
a8390dc 
…per`.

It was caused by a mismatch of the `sig` and `csig` variables when looking the wrapper in the marshalling cache.

This was manifesting as the following crash in all Monodroid programs:

```
#0  mono_type_hash () at /Users/joao/Dev/droid/mono/mono/metadata/metadata.c:1390
#1  0x7512edf4 in mono_signature_hash () at /Users/joao/Dev/droid/mono/mono/metadata/metadata.c:4957
#2  0x75115d18 in signature_pointer_pair_hash () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
#3  0x751dca10 in rehash () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
#4  0x751dcbe0 in monoeg_g_hash_table_insert_replace () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
#5  0x75119570 in mono_mb_create_and_cache_full () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
#6  0x75127390 in mono_marshal_get_native_func_wrapper () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
#7  0x75127780 in mono_ftnptr_to_delegate () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
```

Originally introduced in #1540.
tritao added a commit that referenced this pull request Feb 9, 2015
@tritao
Initialize the counters support before registering new ones.
48b7a50 
This bug manifests itself in mkbundle'd programs that use the machine config support. Under this case, we can end up registering counters before initializing the counter support in the runtime:

```
* thread #1: tid = 0x141dec, 0x003ebdff mtouch-32`mono_counters_register(name=0x0042f7e3, type=2048, addr=0x00b81288) + 31 at mono-counters.c:218, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x003ebdff mtouch-32`mono_counters_register(name=0x0042f7e3, type=2048, addr=0x00b81288) + 31 at mono-counters.c:218
    frame #1: 0x0025c3f6 mtouch-32`mono_loader_init + 198 at loader.c:106
    frame #2: 0x0025f005 mtouch-32`mono_dllmap_insert(assembly=0x00000000, dll=0x00d0a0c0, func=0x00000000, tdll=0x00d0a0d0, tfunc=0x00000000) + 53 at loader.c:1321
    frame #3: 0x002c28ca mtouch-32`dllmap_start(user_data=0x00d0a0b0, element_name=0x00d0a0a0, attribute_names=0x00d0a030, attribute_values=0x00d0a040) + 698 at mono-config.c:290
    frame #4: 0x002c2010 mtouch-32`start_element(context=0x00d09fa0, element_name=0x00d0a0a0, attribute_names=0x00d0a030, attribute_values=0x00d0a040, user_data=0xbffffb68, error=0x00000000) + 240 at mono-config.c:176
    frame #5: 0x0040ba6d mtouch-32`monoeg_g_markup_parse_context_parse(context=0x00d09fa0, text=0x00b72f30, text_len=240, error=0x00000000) + 1965 at gmarkup.c:351
    frame #6: 0x002c0a93 mtouch-32`mono_config_parse_xml_with_context(state=0xbffffb68, text=0x00b72f30, len=240) + 147 at mono-config.c:440
    frame #7: 0x002c09eb mtouch-32`mono_config_parse_memory(buffer=0x00b72f30) + 123 at mono-config.c:482
    frame #8: 0x00001e6d mtouch-32`install_dll_config_files + 29
    frame #9: 0x00001c86 mtouch-32`mono_mkbundle_init + 22
    frame #10: 0x000029db mtouch-32`main + 331
    frame #11: 0x00001c65 mtouch-32`start + 53
```

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=24605.
vkargov pushed a commit to vkargov/mono that referenced this pull request Oct 7, 2015
@schani
Merge pull request mono#1 from vkargov/master
f973d70 
Fix the comma problem, support multiple compiler arguments and add a few optset configs.
@xmcclure xmcclure mentioned this pull request Nov 16, 2015
Merged
lewurm referenced this pull request in lewurm/mono Dec 8, 2015
@lewurm
[runtime] adding additional assert to highlight source of a race
a0e1dae 
We've seen that error for quite some time:

> `* Assertion at ../../mono/utils/mono-os-mutex.h:71, condition `res != EINVAL' not met`

It looks like there's a race between `finalizer_thread()` and `mono_gc_cleanup()` around
`reference_queue_mutex`. The source of the problem is, `finalizer_thread` could end up
being alive, although `mono_gc_cleanup()` made some effort to kill it and then destroys
`reference_queue_mutex`, while the finalizer thread is still using it in
`reference_queue_proccess_all()`.

> $ MONO_GC_DEBUG=bridge=Bridge MONO_GC_PARAMS=minor=split MONO_ENV_OPTIONS=--gc=sgen MONO_PATH=/home/lewurm/monoperf/mono/mcs/class/lib/net_4_x ../../mono/mini/mono sgen-bridge-major-fragmentation.exe --optimize=all --debug
> [...]
> [12/08/2015 01:49:31] done
> Shutting down finalizer thread timed out.
> * Assertion at gc.c:867, condition `finalizer_thread_exited' not met
>
> Stacktrace:
>
>
> Native stacktrace:
>
>
> Debug info from gdb:
>
> [New LWP 7623]
> [New LWP 7622]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
>   Id   Target Id         Frame
>   3    Thread 0x417ff430 (LWP 7622) "mono" 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
>   2    Thread 0x42573430 (LWP 7623) "Finalizer" 0x0021482a in finalizers_with_predicate (predicate=0x1fd121 <object_in_domain_predicate>, user_data=0x37a348, out_array=0x42572c70, out_size=64, hash_table=0x338f68 <major_finalizable_hash>) at sgen-fin-weak-hash.c:581
> * 1    Thread 0x406c4250 (LWP 7620) "mono" 0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
>
> Thread 3 (Thread 0x417ff430 (LWP 7622)):
> #0  0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x404371d8 in pthread_cond_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #2  0x00242266 in mono_os_cond_wait (cond=0x346e98 <work_cond>, mutex=0x346e80 <lock>) at ../../mono/utils/mono-os-mutex.h:105
> mono#3  0x00242c1a in thread_func (thread_data=0x0) at sgen-thread-pool.c:118
> mono#4  0x40433fbc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
> mono#5  0x405a0b3c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 2 (Thread 0x42573430 (LWP 7623)):
> #0  0x0021482a in finalizers_with_predicate (predicate=0x1fd121 <object_in_domain_predicate>, user_data=0x37a348, out_array=0x42572c70, out_size=64, hash_table=0x338f68 <major_finalizable_hash>) at sgen-fin-weak-hash.c:581
> #1  0x00214894 in sgen_gather_finalizers_if (predicate=0x1fd121 <object_in_domain_predicate>, user_data=0x37a348, out_array=0x42572c70, out_size=64) at sgen-fin-weak-hash.c:622
> #2  0x001fd16a in mono_gc_finalizers_for_domain (domain=0x37a348, out_array=0x42572c70, out_size=64) at sgen-mono.c:546
> mono#3  0x001ca2a4 in finalize_domain_objects (req=0x47ba68) at gc.c:678
> mono#4  0x001ca3b6 in finalizer_thread (unused=0x0) at gc.c:730
> mono#5  0x001a1392 in start_wrapper_internal (data=0x3b1100) at threads.c:713
> mono#6  0x001a1430 in start_wrapper (data=0x3b1100) at threads.c:760
> mono#7  0x0027097a in inner_start_thread (arg=0xbed58de0) at mono-threads-posix.c:92
> mono#8  0x40433fbc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
> mono#9  0x405a0b3c in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x406c4250 (LWP 7620)):
> #0  0x4043b5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x4043a396 in waitpid () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #2  0x000d1b24 in mono_handle_native_sigsegv (signal=6, ctx=0xbed58a80, info=0xbed58a00) at mini-exceptions.c:2235
> mono#3  0x00112424 in sigabrt_signal_handler (_dummy=6, _info=0xbed58a00, context=0xbed58a80) at mini-posix.c:218
> mono#4  <signal handler called>
> mono#5  0x405248e6 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> mono#6  0x405330fe in raise () from /lib/arm-linux-gnueabihf/libc.so.6
> mono#7  0x40535956 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
> mono#8  0x00277eaa in monoeg_log_default_handler (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, message=0x47bb28 "* Assertion at gc.c:867, condition `finalizer_thread_exited' not met\n", unused_data=0x0) at goutput.c:233
> mono#9  0x00277dca in monoeg_g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_ERROR, format=0x3089b8 "* Assertion at %s:%d, condition `%s' not met\n", args=...) at goutput.c:113
> mono#10 0x00277e32 in monoeg_assertion_message (format=0x3089b8 "* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:133
> mono#11 0x001ca786 in mono_gc_cleanup () at gc.c:867
> mono#12 0x001c1d24 in mono_runtime_cleanup (domain=0x37a348) at appdomain.c:356
> mono#13 0x0001dec0 in mini_cleanup (domain=0x37a348) at mini-runtime.c:3560
> mono#14 0x000a672c in mono_main (argc=5, argv=0x358098) at driver.c:2065
> mono#15 0x00017c4e in mono_main_with_options (argc=5, argv=0x358098) at main.c:20
> mono#16 0x00017c7e in main (argc=4, argv=0xbed591b4) at main.c:53

=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
@lewurm lewurm mentioned this pull request Dec 8, 2015
Merged
lewurm referenced this pull request in lewurm/mono Feb 2, 2016
@lewurm
[threads] avoid race between setting the state flag and suspension
03f71e6 
there's a short window where we release the lock and another thread
could modify the state.  That is what we saw on the ARM machines for a
while, e.g. in `subthread-exit.cs` there's a race between
`mono_thread_execute_interruption` and `mono_thread_suspend_all_other_threads`:

> Thread 2 (Thread 0x429ff430 (LWP 5189)):  // SUB THREAD
> #0  0x40398e30 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x0028c0ac in monoeg_g_usleep (microseconds=86650) at gdate-unix.c:53
> #2  0x0027b1d8 in suspend_sync_nolock (id=1079603792, interrupt_kernel=1) at mono-threads.c:913
> mono#3  0x0027b2d4 in mono_thread_info_safe_suspend_and_run (id=1079603792, interrupt_kernel=1, callback=0x1ab109 <suspend_thread_critical>, user_data=0x429fe534)
>     at mono-threads.c:935
> mono#4  0x001ab28a in suspend_thread_internal (thread=0x401c0120, interrupt=1) at threads.c:4807
> mono#5  0x001a91ec in mono_thread_suspend_all_other_threads () at threads.c:3297
> mono#6  0x00158d8c in ves_icall_System_Environment_Exit (result=0) at icall.c:6378
> mono#7  0x400e7d9c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x40597250 (LWP 5186)):  // MAIN THREAD
> #0  0x4039a5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x4039796e in do_futex_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #2  0x403979da in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
> mono#3  0x002788d8 in mono_os_sem_wait (sem=0x388248, flags=MONO_SEM_FLAGS_NONE) at ../../mono/utils/mono-os-semaphore.h:163
> mono#4  0x00279722 in mono_thread_info_wait_for_resume (info=0x388210) at mono-threads.c:144
> mono#5  0x0027ad5e in mono_thread_info_end_self_suspend () at mono-threads.c:700
> mono#6  0x001ab2d2 in self_suspend_internal (thread=0x401c0120) at threads.c:4822
> mono#7  0x001aab0a in mono_thread_execute_interruption () at threads.c:4337
> mono#8  0x001a6a82 in ves_icall_System_Threading_Thread_Sleep_internal (ms=1200) at threads.c:1217
> mono#9  0x400da75c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
@lewurm lewurm mentioned this pull request Feb 2, 2016
Merged
monojenkins added a commit that referenced this pull request Feb 3, 2016
@monojenkins
Merge pull request #2558 from lewurm/thread-suspension-race
477d396 
[threads] avoid race between setting the state flag and suspension

there's a short window where we release the lock and another thread
could modify the state.  That is what we saw on the ARM machines for a
while, e.g. in `subthread-exit.cs` there's a race between
`mono_thread_execute_interruption` and `mono_thread_suspend_all_other_threads`:

> Thread 2 (Thread 0x429ff430 (LWP 5189)):  // SUB THREAD
> #0  0x40398e30 in nanosleep () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x0028c0ac in monoeg_g_usleep (microseconds=86650) at gdate-unix.c:53
> #2  0x0027b1d8 in suspend_sync_nolock (id=1079603792, interrupt_kernel=1) at mono-threads.c:913
> #3  0x0027b2d4 in mono_thread_info_safe_suspend_and_run (id=1079603792, interrupt_kernel=1, callback=0x1ab109 <suspend_thread_critical>, user_data=0x429fe534)
>     at mono-threads.c:935
> #4  0x001ab28a in suspend_thread_internal (thread=0x401c0120, interrupt=1) at threads.c:4807
> #5  0x001a91ec in mono_thread_suspend_all_other_threads () at threads.c:3297
> #6  0x00158d8c in ves_icall_System_Environment_Exit (result=0) at icall.c:6378
> #7  0x400e7d9c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x40597250 (LWP 5186)):  // MAIN THREAD
> #0  0x4039a5f4 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x4039796e in do_futex_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #2  0x403979da in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #3  0x002788d8 in mono_os_sem_wait (sem=0x388248, flags=MONO_SEM_FLAGS_NONE) at ../../mono/utils/mono-os-semaphore.h:163
> #4  0x00279722 in mono_thread_info_wait_for_resume (info=0x388210) at mono-threads.c:144
> #5  0x0027ad5e in mono_thread_info_end_self_suspend () at mono-threads.c:700
> #6  0x001ab2d2 in self_suspend_internal (thread=0x401c0120) at threads.c:4822
> #7  0x001aab0a in mono_thread_execute_interruption () at threads.c:4337
> #8  0x001a6a82 in ves_icall_System_Threading_Thread_Sleep_internal (ms=1200) at threads.c:1217
> #9  0x400da75c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
luhenry pushed a commit that referenced this pull request Feb 8, 2016
@akoeplinger
Merge pull request #1 from akoeplinger/mono
6bc0df4 
[System.Numerics] Add support to build with Mono
vargaz pushed a commit that referenced this pull request Mar 31, 2016
@migueldeicaza
Merge pull request #1 from xamarin/hannakim123-patch-1
e3a31c6 
Update for CLA
@joelmartinez joelmartinez mentioned this pull request May 6, 2016
Merged
akoeplinger referenced this pull request in akoeplinger/mono Jun 7, 2016
@akoeplinger
[System] Make TimerTest.EnabledInElapsed more reliable
0b7e88b 
We were seeing intermittent failures on devices like:

```
	[FAIL] TimerTest.EnabledInElapsed :   #1 loss of events
  Expected: True
  But was:  False

		  at MonoTests.System.Timers.TimerTest.EnabledInElapsed () <0x33b168 + 0x0014f> in <filename unknown>:0
		  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
		  at System.Reflection.MonoMethod.Invoke (System.Object , BindingFlags , System.Reflection.Binder , System.Object[] , System.Globalization.CultureInfo ) <0x66d400 + 0x000b7> in <filename unknown>:0
```

Since OS scheduling and GCs can influence the exact timing of the timer intervals sleeping for 200ms is likely just to short.
Instead of bumping the timeout, I decided to rewrite the test to not rely on Thread.Sleep (). I also added another test which
verifies setting AutoResetEvent=false stops the timer event from firing, which was implicitly tested before by the other test.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41530
akoeplinger referenced this pull request in akoeplinger/mono Jun 7, 2016
@akoeplinger
[System] Make TimerTest.EnabledInElapsed more reliable
bab393e 
We were seeing intermittent failures on devices like:

```
	[FAIL] TimerTest.EnabledInElapsed :   #1 loss of events
  Expected: True
  But was:  False

		  at MonoTests.System.Timers.TimerTest.EnabledInElapsed () <0x33b168 + 0x0014f> in <filename unknown>:0
		  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
		  at System.Reflection.MonoMethod.Invoke (System.Object , BindingFlags , System.Reflection.Binder , System.Object[] , System.Globalization.CultureInfo ) <0x66d400 + 0x000b7> in <filename unknown>:0
```

Since OS scheduling and GCs can influence the exact timing of the timer intervals sleeping for 200ms is likely just too short.
Instead of bumping the timeout, I decided to rewrite the test to not rely on Thread.Sleep ().
I also added another test which verifies setting AutoResetEvent=false stops the timer event from firing after the first one,
which was implicitly tested before by the other test.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41530
akoeplinger added a commit that referenced this pull request Jun 8, 2016
@akoeplinger
[System] Make TimerTest.EnabledInElapsed more reliable
1301b26 
We were seeing intermittent failures on devices like:

```
	[FAIL] TimerTest.EnabledInElapsed :   #1 loss of events
  Expected: True
  But was:  False

		  at MonoTests.System.Timers.TimerTest.EnabledInElapsed () <0x33b168 + 0x0014f> in <filename unknown>:0
		  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
		  at System.Reflection.MonoMethod.Invoke (System.Object , BindingFlags , System.Reflection.Binder , System.Object[] , System.Globalization.CultureInfo ) <0x66d400 + 0x000b7> in <filename unknown>:0
```

Since OS scheduling and GCs can influence the exact timing of the timer intervals sleeping for 200ms is likely just too short.
Instead of bumping the timeout, I decided to rewrite the test to not rely on Thread.Sleep ().
I also added another test which verifies setting AutoResetEvent=false stops the timer event from firing after the first one,
which was implicitly tested before by the other test.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41530

(cherry picked from commit bab393e)
akoeplinger referenced this pull request in akoeplinger/mono Jun 8, 2016
@akoeplinger
[System] Make TimerTest.EnabledInElapsed more reliable
b798b01 
We were seeing intermittent failures on devices like:

```
	[FAIL] TimerTest.EnabledInElapsed :   #1 loss of events
  Expected: True
  But was:  False

		  at MonoTests.System.Timers.TimerTest.EnabledInElapsed () <0x33b168 + 0x0014f> in <filename unknown>:0
		  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
		  at System.Reflection.MonoMethod.Invoke (System.Object , BindingFlags , System.Reflection.Binder , System.Object[] , System.Globalization.CultureInfo ) <0x66d400 + 0x000b7> in <filename unknown>:0
```

Since OS scheduling and GCs can influence the exact timing of the timer intervals sleeping for 200ms is likely just too short.
Instead of bumping the timeout, I decided to rewrite the test to not rely on Thread.Sleep ().
I also added another test which verifies setting AutoResetEvent=false stops the timer event from firing after the first one,
which was implicitly tested before by the other test.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41530

(cherry picked from commit bab393e)
grendello added a commit that referenced this pull request Jun 22, 2016
@grendello
Don't run the ping test on certain Android devices
850d468 
As described in https://bugzilla.xamarin.com/show_bug.cgi?id=34883 at
least Samsung SG3 doesn't allow access to the local network
interface (in fact, even ifconfig doesn't work on the device). Therefore
the test needs to be disabled on those devices. This is the first part
of the fix, the second one will be implemented in Xamarin.Android test
suite which will provide the AndroidShouldPingWork method which will
check the device id against list of those that do not work for this
test.

Part #1 of fix for https://bugzilla.xamarin.com/show_bug.cgi?id=34883
monojenkins pushed a commit to monojenkins/mono that referenced this pull request Jan 22, 2020
@lewurm @monojenkins
[interp] context can be uninitialized for get_resume_state callback
9a56505 
`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 mono#1, name = 'tid_407', queue = 'com.apple.main-thread'
    frame #0: 0x0000000190aedc94 libsystem_kernel.dylib`__psynch_cvwait + 8
    frame mono#1: 0x0000000190a0f094 libsystem_pthread.dylib`_pthread_cond_wait$VARIANT$armv81 + 672
    frame mono#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 mono#1: 0x0000000190a0d724 libsystem_pthread.dylib`pthread_kill$VARIANT$armv81 + 216
    frame mono#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 pull request Jan 23, 2020
@monojenkins @lewurm
[interp] context can be uninitialized for get_resume_state callback (#…
455cf7d 
…18535)

`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 #3: 0x0000000104312a68 reloadcontext.iOS`mono_coop_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-coop-mutex.h:91:2
    frame #4: 0x0000000104312858 reloadcontext.iOS`suspend_current at debugger-agent.c:3021:4
    frame #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 #6: 0x0000000104310cf4 reloadcontext.iOS`process_breakpoint_events(_evts=0x000000028351a680, method=0x0000000145d09ae8, ctx=0x0000000149015c20, il_offset=0) at debugger-agent.c:4722:3
    frame #7: 0x000000010432f1c8 reloadcontext.iOS`mono_de_process_breakpoint(void_tls=0x0000000149014e00, from_signal=0) at debugger-engine.c:1141:2
    frame #8: 0x000000010430f238 reloadcontext.iOS`debugger_agent_breakpoint_from_context(ctx=0x000000016f656790) at debugger-agent.c:4938:2
    frame #9: 0x00000001011b73a4 reloadcontext.iOS`sdb_breakpoint_trampoline + 148
    frame #10: 0x00000001008511b4 reloadcontext.iOS`reloadcontext_iOS_Application_Main_string__(args=0x000000010703a030) at Main.cs:14
    frame #11: 0x00000001010f9730 reloadcontext.iOS`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
    frame #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 #13: 0x0000000104411950 reloadcontext.iOS`do_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at object.c:3052:11
    frame #14: 0x000000010440c4dc reloadcontext.iOS`mono_runtime_invoke_checked(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, error=0x000000016f656ff8) at object.c:3220:9
    frame #15: 0x0000000104415ae0 reloadcontext.iOS`do_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5184:3
    frame #16: 0x00000001044144ac reloadcontext.iOS`mono_runtime_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5281:9
    frame #17: 0x0000000104414500 reloadcontext.iOS`mono_runtime_run_main_checked(method=0x0000000145d09ae8, argc=1, argv=0x000000016f6570d0, error=0x000000016f656ff8) at object.c:4734:9
    frame #18: 0x00000001042d3b54 reloadcontext.iOS`mono_jit_exec_internal(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1320:13
    frame #19: 0x00000001042d39a4 reloadcontext.iOS`mono_jit_exec(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1265:7
    frame #20: 0x0000000104597994 reloadcontext.iOS`::xamarin_main(argc=5, argv=0x000000016f657a80, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:483:8
    frame #21: 0x00000001008510dc reloadcontext.iOS`main(argc=5, argv=0x000000016f657a80) at main.m:104:11
    frame #22: 0x0000000190af8360 libdyld.dylib`start + 4
[...]
* thread #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 #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 #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 #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 #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 #7: 0x000000010456061c reloadcontext.iOS`monoeg_assertion_message(format="* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:184:22
    frame #8: 0x0000000104560674 reloadcontext.iOS`mono_assertion_message(file="../../../../../mono/mini/interp/interp.c", line=7176, condition="context") at goutput.c:203:2
    frame #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 #10: 0x0000000104319420 reloadcontext.iOS`compute_frame_info(thread=0x0000000104fe4130, tls=0x0000000149014e00, force_update=1) at debugger-agent.c:3422:3
    frame #11: 0x0000000104320d40 reloadcontext.iOS`thread_commands(command=1, p="", end="", buf=0x000000016fc7acf8) at debugger-agent.c:9048:3
    frame #12: 0x000000010431cca0 reloadcontext.iOS`debugger_thread(arg=0x0000000000000000) at debugger-agent.c:10132:10
    frame #13: 0x000000010447eb04 reloadcontext.iOS`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000000016fc7b000) at threads.c:1232:3
    frame #14: 0x000000010447e788 reloadcontext.iOS`start_wrapper(data=0x000000028203ef40) at threads.c:1305:8
    frame #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

Co-authored-by: Bernhard Urban-Forster <bernhard.urban@xamarin.com>
lewurm added a commit that referenced this pull request Jan 23, 2020
@lewurm
[interp] context can be uninitialized for get_resume_state callback (#…
082662c 
…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 #3: 0x0000000104312a68 reloadcontext.iOS`mono_coop_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-coop-mutex.h:91:2
    frame #4: 0x0000000104312858 reloadcontext.iOS`suspend_current at debugger-agent.c:3021:4
    frame #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 #6: 0x0000000104310cf4 reloadcontext.iOS`process_breakpoint_events(_evts=0x000000028351a680, method=0x0000000145d09ae8, ctx=0x0000000149015c20, il_offset=0) at debugger-agent.c:4722:3
    frame #7: 0x000000010432f1c8 reloadcontext.iOS`mono_de_process_breakpoint(void_tls=0x0000000149014e00, from_signal=0) at debugger-engine.c:1141:2
    frame #8: 0x000000010430f238 reloadcontext.iOS`debugger_agent_breakpoint_from_context(ctx=0x000000016f656790) at debugger-agent.c:4938:2
    frame #9: 0x00000001011b73a4 reloadcontext.iOS`sdb_breakpoint_trampoline + 148
    frame #10: 0x00000001008511b4 reloadcontext.iOS`reloadcontext_iOS_Application_Main_string__(args=0x000000010703a030) at Main.cs:14
    frame #11: 0x00000001010f9730 reloadcontext.iOS`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
    frame #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 #13: 0x0000000104411950 reloadcontext.iOS`do_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at object.c:3052:11
    frame #14: 0x000000010440c4dc reloadcontext.iOS`mono_runtime_invoke_checked(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, error=0x000000016f656ff8) at object.c:3220:9
    frame #15: 0x0000000104415ae0 reloadcontext.iOS`do_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5184:3
    frame #16: 0x00000001044144ac reloadcontext.iOS`mono_runtime_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5281:9
    frame #17: 0x0000000104414500 reloadcontext.iOS`mono_runtime_run_main_checked(method=0x0000000145d09ae8, argc=1, argv=0x000000016f6570d0, error=0x000000016f656ff8) at object.c:4734:9
    frame #18: 0x00000001042d3b54 reloadcontext.iOS`mono_jit_exec_internal(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1320:13
    frame #19: 0x00000001042d39a4 reloadcontext.iOS`mono_jit_exec(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1265:7
    frame #20: 0x0000000104597994 reloadcontext.iOS`::xamarin_main(argc=5, argv=0x000000016f657a80, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:483:8
    frame #21: 0x00000001008510dc reloadcontext.iOS`main(argc=5, argv=0x000000016f657a80) at main.m:104:11
    frame #22: 0x0000000190af8360 libdyld.dylib`start + 4
[...]
* thread #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 #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 #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 #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 #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 #7: 0x000000010456061c reloadcontext.iOS`monoeg_assertion_message(format="* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:184:22
    frame #8: 0x0000000104560674 reloadcontext.iOS`mono_assertion_message(file="../../../../../mono/mini/interp/interp.c", line=7176, condition="context") at goutput.c:203:2
    frame #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 #10: 0x0000000104319420 reloadcontext.iOS`compute_frame_info(thread=0x0000000104fe4130, tls=0x0000000149014e00, force_update=1) at debugger-agent.c:3422:3
    frame #11: 0x0000000104320d40 reloadcontext.iOS`thread_commands(command=1, p="", end="", buf=0x000000016fc7acf8) at debugger-agent.c:9048:3
    frame #12: 0x000000010431cca0 reloadcontext.iOS`debugger_thread(arg=0x0000000000000000) at debugger-agent.c:10132:10
    frame #13: 0x000000010447eb04 reloadcontext.iOS`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000000016fc7b000) at threads.c:1232:3
    frame #14: 0x000000010447e788 reloadcontext.iOS`start_wrapper(data=0x000000028203ef40) at threads.c:1305:8
    frame #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 pull request Jan 24, 2020
@monojenkins @lewurm
[interp] context can be uninitialized for get_resume_state callback (#…
ea94456 
…18536)

`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 #3: 0x0000000104312a68 reloadcontext.iOS`mono_coop_cond_wait(cond=0x0000000104b9ba78, mutex=0x0000000104b9ba30) at mono-coop-mutex.h:91:2
    frame #4: 0x0000000104312858 reloadcontext.iOS`suspend_current at debugger-agent.c:3021:4
    frame #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 #6: 0x0000000104310cf4 reloadcontext.iOS`process_breakpoint_events(_evts=0x000000028351a680, method=0x0000000145d09ae8, ctx=0x0000000149015c20, il_offset=0) at debugger-agent.c:4722:3
    frame #7: 0x000000010432f1c8 reloadcontext.iOS`mono_de_process_breakpoint(void_tls=0x0000000149014e00, from_signal=0) at debugger-engine.c:1141:2
    frame #8: 0x000000010430f238 reloadcontext.iOS`debugger_agent_breakpoint_from_context(ctx=0x000000016f656790) at debugger-agent.c:4938:2
    frame #9: 0x00000001011b73a4 reloadcontext.iOS`sdb_breakpoint_trampoline + 148
    frame #10: 0x00000001008511b4 reloadcontext.iOS`reloadcontext_iOS_Application_Main_string__(args=0x000000010703a030) at Main.cs:14
    frame #11: 0x00000001010f9730 reloadcontext.iOS`wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 272
    frame #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 #13: 0x0000000104411950 reloadcontext.iOS`do_runtime_invoke(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, exc=0x0000000000000000, error=0x000000016f656ff8) at object.c:3052:11
    frame #14: 0x000000010440c4dc reloadcontext.iOS`mono_runtime_invoke_checked(method=0x0000000145d09ae8, obj=0x0000000000000000, params=0x000000016f656f20, error=0x000000016f656ff8) at object.c:3220:9
    frame #15: 0x0000000104415ae0 reloadcontext.iOS`do_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5184:3
    frame #16: 0x00000001044144ac reloadcontext.iOS`mono_runtime_exec_main_checked(method=0x0000000145d09ae8, args=0x000000010703a030, error=0x000000016f656ff8) at object.c:5281:9
    frame #17: 0x0000000104414500 reloadcontext.iOS`mono_runtime_run_main_checked(method=0x0000000145d09ae8, argc=1, argv=0x000000016f6570d0, error=0x000000016f656ff8) at object.c:4734:9
    frame #18: 0x00000001042d3b54 reloadcontext.iOS`mono_jit_exec_internal(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1320:13
    frame #19: 0x00000001042d39a4 reloadcontext.iOS`mono_jit_exec(domain=0x0000000145f00130, assembly=0x0000000281ba2900, argc=1, argv=0x000000016f6570d0) at driver.c:1265:7
    frame #20: 0x0000000104597994 reloadcontext.iOS`::xamarin_main(argc=5, argv=0x000000016f657a80, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:483:8
    frame #21: 0x00000001008510dc reloadcontext.iOS`main(argc=5, argv=0x000000016f657a80) at main.m:104:11
    frame #22: 0x0000000190af8360 libdyld.dylib`start + 4
[...]
* thread #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 #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 #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 #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 #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 #7: 0x000000010456061c reloadcontext.iOS`monoeg_assertion_message(format="* Assertion at %s:%d, condition `%s' not met\n") at goutput.c:184:22
    frame #8: 0x0000000104560674 reloadcontext.iOS`mono_assertion_message(file="../../../../../mono/mini/interp/interp.c", line=7176, condition="context") at goutput.c:203:2
    frame #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 #10: 0x0000000104319420 reloadcontext.iOS`compute_frame_info(thread=0x0000000104fe4130, tls=0x0000000149014e00, force_update=1) at debugger-agent.c:3422:3
    frame #11: 0x0000000104320d40 reloadcontext.iOS`thread_commands(command=1, p="", end="", buf=0x000000016fc7acf8) at debugger-agent.c:9048:3
    frame #12: 0x000000010431cca0 reloadcontext.iOS`debugger_thread(arg=0x0000000000000000) at debugger-agent.c:10132:10
    frame #13: 0x000000010447eb04 reloadcontext.iOS`start_wrapper_internal(start_info=0x0000000000000000, stack_ptr=0x000000016fc7b000) at threads.c:1232:3
    frame #14: 0x000000010447e788 reloadcontext.iOS`start_wrapper(data=0x000000028203ef40) at threads.c:1305:8
    frame #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

Co-authored-by: Bernhard Urban-Forster <bernhard.urban@xamarin.com>
@ArseeniK ArseeniK mentioned this pull request Jan 31, 2020
Open
@fanyang-mono fanyang-mono mentioned this pull request Mar 3, 2020
Closed
@eNTi eNTi mentioned this pull request Mar 5, 2020
Closed
monojenkins pushed a commit to monojenkins/runtime that referenced this pull request May 25, 2020
@grendello
[reflection] Check whether a pointer is valid before dereferencing
b0bd19e 
`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   :       mono/mono#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   :       mono/mono#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   :       mono/mono#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/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/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/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.

<!--
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
-->
monojenkins pushed a commit to monojenkins/mono that referenced this pull request May 25, 2020
@grendello @monojenkins
[reflection] Check whether a pointer is valid before dereferencing
53b5cd0 
`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   :       mono#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   :       mono#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.
lambdageek pushed a commit that referenced this pull request May 26, 2020
@grendello
[reflection] Check whether a pointer is valid before dereferencing (#…
53d0017 
…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   :       #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   :       #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   :       #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.
lambdageek pushed a commit to dotnet/runtime that referenced this pull request May 26, 2020
@monojenkins @grendello
[reflection] Check whether a pointer is valid before dereferencing (#…
2d88a3d 
…36981)

`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   :       mono/mono#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   :       mono/mono#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   :       mono/mono#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/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/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/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.

<!--
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
-->

Co-authored-by: grendello <grendello@users.noreply.github.com>
lambdageek pushed a commit that referenced this pull request May 26, 2020
@monojenkins @grendello
[reflection] Check whether a pointer is valid before dereferencing (#…
8c085a9 
…19842)

`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   :       #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   :       #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   :       #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.

Co-authored-by: Marek Habersack <grendel@twistedcode.net>
@n432sean n432sean mentioned this pull request Jul 29, 2020
Open
@thenapster thenapster mentioned this pull request Aug 18, 2021
Open
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@luhenry
[threaddpool] Fix deadlock in thread pool with monitor thread
e3c1eb3 
Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit.

Thread 7 (Thread 0x1c13 of process 99776):
mono/mono#0  0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib
mono/mono#1  0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103
mono/mono#2  0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898
mono/mono#3  0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657
mono/mono#4  0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704
mono/mono#5  0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84
mono/mono#6  0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#7  0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#8  0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#9  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x1503 of process 99776):
mono/mono#0  0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib
mono/mono#1  0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#2  0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595
mono/mono#3  0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540
mono/mono#4  0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194
mono/mono#5  0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516
mono/mono#6  0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658
mono/mono#7  0x00000001002c70e5 in mono_thread_manage () at threads.c:2951
mono/mono#8  0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021
mono/mono#9  0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91
mono/mono#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122


Commit migrated from mono/mono@478f99f
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@luhenry
[threaddpool] Fix deadlock in thread pool with monitor thread (2nd at…
f55a8c7 
…tempt)

Because the monitor thread was not marked as background thread, remove_and_abort_threads (threads.c:2807) would mark it as needed to be waited to shutdown the runtime, and wait_for_tids (threads.c:2652) would then wait indefinitely for it to finish. The issue was that the monitor was waiting on the semaphore monitor_sem, and thus would never exit.

Thread 7 (Thread 0x1c13 of process 99776):
mono/mono#0  0x00007fff86590a56 in ?? () from /usr/lib/system/libsystem_kernel.dylib
mono/mono#1  0x00000001003cc03a in mono_sem_wait (sem=0x1004f7f50, alertable=0) at mono-semaphore.c:103
mono/mono#2  0x00000001002cef41 in monitor_thread (unused=0x0) at threadpool.c:898
mono/mono#3  0x00000001002cb78f in start_wrapper_internal (data=0x10500abf0) at threads.c:657
mono/mono#4  0x00000001002cb4a1 in start_wrapper (data=0x10500abf0) at threads.c:704
mono/mono#5  0x00000001003d61d4 in inner_start_thread (arg=0x7fff5fbfe500) at mono-threads-posix.c:84
mono/mono#6  0x00007fff8e7c9899 in _pthread_body () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#7  0x00007fff8e7c972a in _pthread_start () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#8  0x00007fff8e7cdfc9 in thread_start () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#9  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x1503 of process 99776):
mono/mono#0  0x00007fff86594716 in ?? () from /usr/lib/system/libsystem_kernel.dylib
mono/mono#1  0x00007fff8e7cbc3b in _pthread_cond_wait () from /usr/lib/system/libsystem_pthread.dylib
mono/mono#2  0x000000010039cfaa in _wapi_handle_timedwait_signal_handle (handle=0xa55, timeout=0x0, alertable=1, poll=0) at handles.c:1595
mono/mono#3  0x000000010039d03d in _wapi_handle_wait_signal_handle (handle=0xa55, alertable=1) at handles.c:1540
mono/mono#4  0x00000001003b7ba3 in WaitForSingleObjectEx (handle=0xa55, timeout=4294967295, alertable=1) at wait.c:194
mono/mono#5  0x00000001003b865d in WaitForMultipleObjectsEx (numobjects=1, handles=0x7fff5fbff1f8, waitall=1, timeout=4294967295, alertable=1) at wait.c:516
mono/mono#6  0x00000001002c75df in wait_for_tids (wait=0x7fff5fbff1f8, timeout=4294967295) at threads.c:2658
mono/mono#7  0x00000001002c70e5 in mono_thread_manage () at threads.c:2951
mono/mono#8  0x00000001000d551b in mono_main (argc=6, argv=0x7fff5fbff9e8) at driver.c:2021
mono/mono#9  0x0000000100001bd1 in mono_main_with_options (argc=6, argv=0x7fff5fbff9e8) at ./main.c:91
mono/mono#10 0x00000001000017d3 in main (argc=6, argv=0x7fff5fbff9e8) at ./main.c:122

Thanks @akoeplinger for the help debugging


Commit migrated from mono/mono@98ce3f7
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@luhenry
[threadpool] Fix deadlock/starvation of the thread pool
99d823f 
The issue was with the new heuristic of the thread pool which would not create new threads, leading to deadlock between dependent tasks.
The fix is to check if every worker threads are sleeping, waiting or joining, and if that's the case, then we create a new thread because we might be in the case where the tasks being currently run depends on one still being enqueued in the cq or one of the wsq.

The following tests would previously fail :

1) MonoTests.System.Threading.Tasks.TaskTests.DoubleWaitTest :   mono/mono#1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.<DoubleWaitTest>m__27 () [0x00077] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:800
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action, Int32 numRun) [0x00007] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:48
at MonoTests.System.Threading.Tasks.TaskTests.DoubleWaitTest () [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:790
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

2) MonoTests.System.Threading.Tasks.TaskTests.HideSchedulerTest :   mono/mono#1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.HideSchedulerTest () [0x0003d] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:1914
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

3) MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsAfter :   mono/mono#1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsAfter () [0x00070] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:317
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

4) MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsBefore :   mono/mono#1
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.WaitAll_TimeoutWithExceptionsBefore () [0x00070] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:341
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

5) MonoTests.System.Threading.Tasks.TaskTests.WaitAnyTest :   mono/mono#3
  Expected: not -1
  But was:  -1

at MonoTests.System.Threading.Tasks.TaskTests.<WaitAnyTest>m__0 () [0x00026] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:142
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action, Int32 numRun) [0x00007] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:48
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action) [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:42
at MonoTests.System.Threading.Tasks.TaskTests.WaitAnyTest () [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:128
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

6) MonoTests.System.Threading.Tasks.TaskTests.WaitChildTestCase :   mono/mono#0b
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.<WaitChildTestCase>m__25 () [0x0006d] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:705
at MonoTests.System.Threading.Tasks.ParallelTestHelper.Repeat (System.Action action, Int32 numRun) [0x00007] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/ParallelTestHelper.cs:48
at MonoTests.System.Threading.Tasks.TaskTests.WaitChildTestCase () [0x00000] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:684
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230

7) MonoTests.System.Threading.Tasks.TaskTests.WaitingForChildrenToComplete :   mono/mono#3
  Expected: True
  But was:  False

at MonoTests.System.Threading.Tasks.TaskTests.WaitingForChildrenToComplete () [0x00048] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/Test/System.Threading.Tasks/TaskTest.cs:734
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00054] in /Users/ludovic/Xamarin/mono/mcs/class/corlib/System.Reflection/MonoMethod.cs:230


Commit migrated from mono/mono@a142d92
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
Fix build errors in mono-context.c on ppc64el
7251aac 
Build error mono/mono#1:

	libtool: compile:  gcc <...> -c mono-context.c  -fPIC -DPIC -o .libs/mono-context.o
	mono-context.c: In function 'mono_sigctx_to_monoctx':
	mono-context.c:435:68: error: 'MONO_SAVED_GREGS' undeclared (first use in this function)
	  memcpy (&mctx->regs, &UCONTEXT_REG_Rn(uc, 13), sizeof (mgreg_t) * MONO_SAVED_GREGS);
		                                                            ^
	mono-context.c:435:68: note: each undeclared identifier is reported only once for each function it appears in
	mono-context.c:436:70: error: 'MONO_SAVED_FREGS' undeclared (first use in this function)
	  memcpy (&mctx->fregs, &UCONTEXT_REG_FPRn(uc, 14), sizeof (double) * MONO_SAVED_FREGS);
		                                                              ^
The MONO_SAVED_GREGS and MONO_SAVED_FREGS macros are defined in mini-ppc.h.
The problem happens because commit mono/mono@7e056cd
moved code using them from exceptions-ppc.h (which includes mini-ppc.h) to
mono-context.c (which doesn't), where they're not #included.

So, include mini-ppc.h in mono-context.c (in the existing powerpc ifdef block).

Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>

Build error mono/mono#2:

Now, it turns out mini-ppc.h doesn't know MonoMethod, MonoMethodSignature, and MonoObject.
So, include object.h (MonoObject), which includes metadata.h (MonoMethod and MonoMethodSignature),
in mini-ppc.h.

	libtool: compile: gcc <...>  -c mono-context.c  -fPIC -DPIC -o .libs/mono-context.o
	In file included from mono-context.c:427:0:
	../../mono/mini/mini-ppc.h:37:2: error: unknown type name 'MonoMethod'
	  MonoMethod *method;
	  ^
	../../mono/mini/mini-ppc.h:306:31: error: unknown type name 'MonoMethodSignature'
	 mono_ppc_tail_call_supported (MonoMethodSignature *caller_sig, MonoMethodSignature *callee_sig) MONO_INTERNAL;
		                       ^
	../../mono/mini/mini-ppc.h:306:64: error: unknown type name 'MonoMethodSignature'
	 mono_ppc_tail_call_supported (MonoMethodSignature *caller_sig, MonoMethodSignature *callee_sig) MONO_INTERNAL;
		                                                        ^
	../../mono/mini/mini-ppc.h:312:27: error: unknown type name 'MonoObject'
	 mono_ppc_throw_exception (MonoObject *exc, unsigned long eip, unsigned long esp, mgreg_t *int_regs, gdouble *fp_regs, gboolean rethrow) MONO_INTERNAL;
		                   ^

Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>


Commit migrated from mono/mono@e36ef8b
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
Fix build errors in mono-context.c on ppc64el
5a35e6f 
Build error mono/mono#1:

	libtool: compile:  gcc <...> -c mono-context.c  -fPIC -DPIC -o .libs/mono-context.o
	mono-context.c: In function 'mono_sigctx_to_monoctx':
	mono-context.c:435:68: error: 'MONO_SAVED_GREGS' undeclared (first use in this function)
	  memcpy (&mctx->regs, &UCONTEXT_REG_Rn(uc, 13), sizeof (mgreg_t) * MONO_SAVED_GREGS);
		                                                            ^
	mono-context.c:435:68: note: each undeclared identifier is reported only once for each function it appears in
	mono-context.c:436:70: error: 'MONO_SAVED_FREGS' undeclared (first use in this function)
	  memcpy (&mctx->fregs, &UCONTEXT_REG_FPRn(uc, 14), sizeof (double) * MONO_SAVED_FREGS);
		                                                              ^
The MONO_SAVED_GREGS and MONO_SAVED_FREGS macros are defined in mini-ppc.h.
The problem happens because commit mono/mono@7e056cd
moved code using them from exceptions-ppc.h (which includes mini-ppc.h) to
mono-context.c (which doesn't), where they're not #included.

So, include mini-ppc.h in mono-context.c (in the existing powerpc ifdef block).

Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>

Build error mono/mono#2:

Now, it turns out mini-ppc.h doesn't know MonoMethod, MonoMethodSignature, and MonoObject.
So, include object.h (MonoObject), which includes metadata.h (MonoMethod and MonoMethodSignature),
in mini-ppc.h.

	libtool: compile: gcc <...>  -c mono-context.c  -fPIC -DPIC -o .libs/mono-context.o
	In file included from mono-context.c:427:0:
	../../mono/mini/mini-ppc.h:37:2: error: unknown type name 'MonoMethod'
	  MonoMethod *method;
	  ^
	../../mono/mini/mini-ppc.h:306:31: error: unknown type name 'MonoMethodSignature'
	 mono_ppc_tail_call_supported (MonoMethodSignature *caller_sig, MonoMethodSignature *callee_sig) MONO_INTERNAL;
		                       ^
	../../mono/mini/mini-ppc.h:306:64: error: unknown type name 'MonoMethodSignature'
	 mono_ppc_tail_call_supported (MonoMethodSignature *caller_sig, MonoMethodSignature *callee_sig) MONO_INTERNAL;
		                                                        ^
	../../mono/mini/mini-ppc.h:312:27: error: unknown type name 'MonoObject'
	 mono_ppc_throw_exception (MonoObject *exc, unsigned long eip, unsigned long esp, mgreg_t *int_regs, gdouble *fp_regs, gboolean rethrow) MONO_INTERNAL;
		                   ^

Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>


Commit migrated from mono/mono@55fa0a5
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@tritao
[runtime] Fixed marshalling bug in `mono_marshal_get_native_func_wrap…
f858f15 
…per`.

It was caused by a mismatch of the `sig` and `csig` variables when looking the wrapper in the marshalling cache.

This was manifesting as the following crash in all Monodroid programs:

```
mono/mono#0  mono_type_hash () at /Users/joao/Dev/droid/mono/mono/metadata/metadata.c:1390
mono/mono#1  0x7512edf4 in mono_signature_hash () at /Users/joao/Dev/droid/mono/mono/metadata/metadata.c:4957
mono/mono#2  0x75115d18 in signature_pointer_pair_hash () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
mono/mono#3  0x751dca10 in rehash () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
mono/mono#4  0x751dcbe0 in monoeg_g_hash_table_insert_replace () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
mono/mono#5  0x75119570 in mono_mb_create_and_cache_full () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
mono/mono#6  0x75127390 in mono_marshal_get_native_func_wrapper () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
mono/mono#7  0x75127780 in mono_ftnptr_to_delegate () from /Users/joao/Dev/droid/monodroid/tests/runtime/gdb-symbols/libmonosgen-2.0.so
```

Originally introduced in mono/mono#1540.


Commit migrated from mono/mono@a8390dc
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@tritao
Initialize the counters support before registering new ones.
c6b055b 
This bug manifests itself in mkbundle'd programs that use the machine config support. Under this case, we can end up registering counters before initializing the counter support in the runtime:

```
* thread mono/mono#1: tid = 0x141dec, 0x003ebdff mtouch-32`mono_counters_register(name=0x0042f7e3, type=2048, addr=0x00b81288) + 31 at mono-counters.c:218, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame mono/mono#0: 0x003ebdff mtouch-32`mono_counters_register(name=0x0042f7e3, type=2048, addr=0x00b81288) + 31 at mono-counters.c:218
    frame mono/mono#1: 0x0025c3f6 mtouch-32`mono_loader_init + 198 at loader.c:106
    frame mono/mono#2: 0x0025f005 mtouch-32`mono_dllmap_insert(assembly=0x00000000, dll=0x00d0a0c0, func=0x00000000, tdll=0x00d0a0d0, tfunc=0x00000000) + 53 at loader.c:1321
    frame mono/mono#3: 0x002c28ca mtouch-32`dllmap_start(user_data=0x00d0a0b0, element_name=0x00d0a0a0, attribute_names=0x00d0a030, attribute_values=0x00d0a040) + 698 at mono-config.c:290
    frame mono/mono#4: 0x002c2010 mtouch-32`start_element(context=0x00d09fa0, element_name=0x00d0a0a0, attribute_names=0x00d0a030, attribute_values=0x00d0a040, user_data=0xbffffb68, error=0x00000000) + 240 at mono-config.c:176
    frame mono/mono#5: 0x0040ba6d mtouch-32`monoeg_g_markup_parse_context_parse(context=0x00d09fa0, text=0x00b72f30, text_len=240, error=0x00000000) + 1965 at gmarkup.c:351
    frame mono/mono#6: 0x002c0a93 mtouch-32`mono_config_parse_xml_with_context(state=0xbffffb68, text=0x00b72f30, len=240) + 147 at mono-config.c:440
    frame mono/mono#7: 0x002c09eb mtouch-32`mono_config_parse_memory(buffer=0x00b72f30) + 123 at mono-config.c:482
    frame mono/mono#8: 0x00001e6d mtouch-32`install_dll_config_files + 29
    frame mono/mono#9: 0x00001c86 mtouch-32`mono_mkbundle_init + 22
    frame mono/mono#10: 0x000029db mtouch-32`main + 331
    frame mono/mono#11: 0x00001c65 mtouch-32`start + 53
```

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=24605.


Commit migrated from mono/mono@48b7a50
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@luhenry
[pedump] Fix assertion error
af59053 
We would previously observe the following crash:

```
ludovic-laptop :: ~/Xamarin/mono ‹16c07b5› » (cd tools/pedump && MONO_PATH=../../mcs/class/lib/net_4_x lldb -- ./pedump --verify metadata,code ../.././mono/tests/xdomain-threads.exe)
(lldb) target create "./pedump"
Current executable set to './pedump' (x86_64).
(lldb) settings set -- target.run-args  "--verify" "metadata,code" "../.././mono/tests/xdomain-threads.exe"
(lldb) r
Process 14407 launched: './pedump' (x86_64)
mono_os_mutex_lock: pthread_mutex_lock failed with "Invalid argument" (22)
Process 14407 stopped
* thread mono/mono#1: tid = 0x27c9715, 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame mono/mono#0: 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10
	libsystem_kernel.dylib`__pthread_kill:
	->  0x7fff93cfcf06 <+10>: jae    0x7fff93cfcf10            ; <+20>
	    0x7fff93cfcf08 <+12>: movq   %rax, %rdi
        0x7fff93cfcf0b <+15>: jmp    0x7fff93cf77cd            ; cerror_nocancel
	    0x7fff93cfcf10 <+20>: retq
(lldb) bt
* thread mono/mono#1: tid = 0x27c9715, 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame mono/mono#0: 0x00007fff93cfcf06 libsystem_kernel.dylib`__pthread_kill + 10
    frame mono/mono#1: 0x00007fff8b9b74ec libsystem_pthread.dylib`pthread_kill + 90
	frame mono/mono#2: 0x00007fff908d56e7 libsystem_c.dylib`abort + 129
	frame mono/mono#3: 0x000000010022da6a pedump`monoeg_log_default_handler(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, message="mono_os_mutex_lock: pthread_mutex_lock failed with \"Invalid argument\" (22)", unused_data=0x0000000000000000) + 202 at goutput.c:231
	frame mono/mono#4: 0x000000010022d98d pedump`monoeg_g_logv(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="%s: pthread_mutex_lock failed with \"%s\" (%d)", args=0x00007fff5fbff4a0) + 109 at goutput.c:111
	frame mono/mono#5: 0x000000010022dbd9 pedump`monoeg_g_log(log_domain=0x0000000000000000, log_level=G_LOG_LEVEL_ERROR, format="%s: pthread_mutex_lock failed with \"%s\" (%d)") + 361 at goutput.c:121
	frame mono/mono#6: 0x000000010022301e pedump`mono_os_mutex_lock(mutex=0x00000001002ec630) + 110 at mono-os-mutex.h:98
	frame mono/mono#7: 0x0000000100223a66 pedump`mono_w32handle_new(type=MONO_W32HANDLE_PROCESS, handle_specific=0x00007fff5fbff540) + 246 at w32handle.c:440
	frame mono/mono#8: 0x00000001001ef8bb pedump`_wapi_processes_init + 123 at processes.c:1149
	frame mono/mono#9: 0x00000001001fbcc3 pedump`wapi_init + 19 at wapi.c:23
	frame mono/mono#10: 0x0000000100116486 pedump`mono_init_internal(filename="pedump", exe_filename=0x0000000000000000, runtime_version="v4.0.30319") + 102 at domain.c:528
	frame mono/mono#11: 0x0000000100117124 pedump`mono_init_version(domain_name="pedump", version="v4.0.30319") + 36 at domain.c:868
	frame mono/mono#12: 0x0000000100001496 pedump`verify_image_file(fname="../.././mono/tests/xdomain-threads.exe") + 678 at pedump.c:466
	frame mono/mono#13: 0x0000000100000f87 pedump`main(argc=4, argv=0x00007fff5fbff9a0) + 1095 at pedump.c:708
	frame mono/mono#14: 0x00007fff93e655ad libdyld.dylib`start + 1
```

That would be because the w32handle wouldn't be initialized before calling into `wapi_init` which allocates w32handle.


Commit migrated from mono/mono@e8a2216
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@luhenry
[threads] Fix async call in coop (mono/mono#4423)
15e0c35 
We would observe crashes like the following:

```
 * Assertion at mono-threads.c:1009, condition `mono_thread_info_run_state (info) == STATE_ASYNC_SUSPENDED' not met

 Debug info from gdb:

 [New LWP 26793]
 [New LWP 26792]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 0x00002b0ff3481ee9 in waitpid () from /lib/x86_64-linux-gnu/libpthread.so.0
   Id   Target Id         Frame
   3    Thread 0x2b0ff3e6c700 (LWP 26792) "SGen worker" 0x00002b0ff347e414 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
   2    Thread 0x2b0ff633e700 (LWP 26793) "Finalizer" 0x00002b0ff347e414 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
 * 1    Thread 0x2b0ff2b67c40 (LWP 26780) "mono" 0x00002b0ff3481ee9 in waitpid () from /lib/x86_64-linux-gnu/libpthread.so.0

 Thread 3 (Thread 0x2b0ff3e6c700 (LWP 26792)):
 mono/mono#0  0x00002b0ff347e414 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
 mono/mono#1  0x0000000000661bdf in mono_os_cond_wait (mutex=0x9dee40 <lock>, cond=0x9dee00 <work_cond>) at ../../mono/utils/mono-os-mutex.h:146
 mono/mono#2  thread_func (thread_data=0x2b0ff2bcb008) at sgen-thread-pool.c:129
 mono/mono#3  0x00002b0ff347a182 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
 mono/mono#4  0x00002b0ff39a130d in clone () from /lib/x86_64-linux-gnu/libc.so.6

 Thread 2 (Thread 0x2b0ff633e700 (LWP 26793)):
 mono/mono#0  0x00002b0ff347e414 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
 mono/mono#1  0x00000000005caff3 in mono_os_cond_wait (mutex=<optimized out>, cond=<optimized out>) at ../../mono/utils/mono-os-mutex.h:146
 mono/mono#2  mono_coop_cond_wait (mutex=<optimized out>, cond=<optimized out>) at ../../mono/utils/mono-coop-mutex.h:87
 mono/mono#3  mono_threadpool_io_remove_socket (fd=134239440) at threadpool-io.c:628
 mono/mono#4  0x00000000005ae4f4 in ves_icall_System_Net_Sockets_Socket_Close_internal (sock=42, werror=<optimized out>) at w32socket.c:708
 mono/mono#5  0x0000000041e8101f in ?? ()
 mono/mono#6  0x00002b1014abe070 in ?? ()
 mono/mono#7  0x0000000001615860 in ?? ()
 mono/mono#8  0x0000000001615860 in ?? ()
 mono/mono#9  0x0000000000000000 in ?? ()

 Thread 1 (Thread 0x2b0ff2b67c40 (LWP 26780)):
 mono/mono#0  0x00002b0ff3481ee9 in waitpid () from /lib/x86_64-linux-gnu/libpthread.so.0
 mono/mono#1  0x00000000004ac5e6 in mono_handle_native_crash (signal=<optimized out>, ctx=<optimized out>, info=<optimized out>) at mini-exceptions.c:2557
 mono/mono#2  <signal handler called>
 mono/mono#3  0x00002b0ff38dcf79 in raise () from /lib/x86_64-linux-gnu/libc.so.6
 mono/mono#4  0x00002b0ff38e0388 in abort () from /lib/x86_64-linux-gnu/libc.so.6
 mono/mono#5  0x000000000066b459 in mono_log_write_logfile (log_domain=<optimized out>, level=<optimized out>, hdr=<optimized out>, message=<optimized out>) at mono-log-common.c:137
 mono/mono#6  0x00000000006805e0 in monoeg_g_logv (log_domain=log_domain@entry=0x0, log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry=0x7ffc7324ea78) at goutput.c:115
 mono/mono#7  0x0000000000680736 in monoeg_assertion_message (format=<optimized out>) at goutput.c:135
 mono/mono#8  0x00000000006759b8 in mono_thread_info_setup_async_call (info=info@entry=0x2b0ff80008c0, target_func=target_func@entry=0x5bac20 <suspend_for_shutdown_async_call>, user_data=user_data@entry=0x0) at mono-threads.c:1009
 mono/mono#9  0x00000000005bad50 in suspend_for_shutdown_critical (info=info@entry=0x2b0ff80008c0, unused=unused@entry=0x0) at threads.c:5019
 mono/mono#10 0x00000000006763ae in mono_thread_info_safe_suspend_and_run (id=47347555100416, interrupt_kernel=interrupt_kernel@entry=0, callback=callback@entry=0x5bad40 <suspend_for_shutdown_critical>, user_data=user_data@entry=0x0) at mono-threads.c:979
 mono/mono#11 0x00000000005c2e71 in mono_thread_internal_suspend_for_shutdown (thread=<optimized out>) at threads.c:5028
 mono/mono#12 0x00000000005e9100 in mono_gc_cleanup () at gc.c:1015
 mono/mono#13 0x00000000005e108e in mono_runtime_cleanup (domain=domain@entry=0x1615860) at appdomain.c:423
 mono/mono#14 0x00000000004228cb in mini_cleanup (domain=0x1615860) at mini-runtime.c:4111
 mono/mono#15 0x000000000047b99f in mono_main (argc=10, argv=<optimized out>) at driver.c:2167
 mono/mono#16 0x00000000004200db in mono_main_with_options (argv=0x7ffc7324ef68, argc=10) at main.c:45
 mono/mono#17 main (argc=10, argv=0x7ffc7324ef68) at main.c:338

 =================================================================
 Got a SIGABRT while executing native code. This usually indicates
 a fatal error in the mono runtime or one of the native libraries
 used by your application.
 =================================================================
```

Commit migrated from mono/mono@98a369f
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@akoeplinger
Revert "[marshal] delay dummy string allocation"
6ff8310 
Reverts mono/mono@5e23a77

It seems to cause a crash during msbuild tests:

```
  xunit -> Microsoft.Build.Engine.UnitTests...
  Stacktrace:

  Native stacktrace:

  	0   mono                                0x0017cad4 mono_handle_native_crash + 308
  	1   mono                                0x001e2b03 sigabrt_signal_handler + 147
  	2   libsystem_platform.dylib            0x920a8deb _sigtramp + 43
  	3   ???                                 0xffffffff 0x0 + 4294967295
  	4   libsystem_c.dylib                   0x940bb27c abort + 155
  	5   mono                                0x0036886d mono_log_write_logfile + 381
  	6   mono                                0x003630d2 structured_log_adapter + 50
  	7   mono                                0x00380d1b monoeg_assertion_message + 107
  	8   mono                                0x0033863d major_scan_object_with_evacuation + 3373
  	9   mono                                0x0033b3d0 drain_gray_stack + 6608
  	10  mono                                0x0032df57 finish_gray_stack + 151
  	11  mono                                0x0032d3c6 major_finish_collection + 118
  	12  mono                                0x00329909 major_do_collection + 169
  	13  mono                                0x003288bd sgen_perform_collection + 605
  	14  mono                                0x0032a90b sgen_gc_collect + 75
  	15  mono                                0x002d5c4d unload_thread_main + 861
  	16  mono                                0x002abb6b start_wrapper + 795
  	17  libsystem_pthread.dylib             0x9ae6d5fb _pthread_body + 144
  	18  libsystem_pthread.dylib             0x9ae6d485 _pthread_struct_init + 0
  	19  libsystem_pthread.dylib             0x9ae72cf2 thread_start + 34

  Debug info from gdb:

  (lldb) command source -s 0 '/tmp/mono-gdb-commands.2tso9f'
  Executing commands in '/tmp/mono-gdb-commands.2tso9f'.
  (lldb) process attach --pid 2037
  2017-06-02 13:07:23.000 lldb[2093:282f] Metadata.framework [Error]: couldn't get the client port
  Process 2037 stopped
  * thread mono/mono#1, name = 'tid_507', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
      frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
  libsystem_kernel.dylib`__psynch_cvwait:
  ->  0x923cc7ca <+10>: jae    0x923cc7da                ; <+26>
      0x923cc7cc <+12>: calll  0x923cc7d1                ; <+17>
      0x923cc7d1 <+17>: popl   %edx
      0x923cc7d2 <+18>: movl   0xe0b084f(%edx), %edx

  Executable module set to "/Users/builder/data/lanes/2716/mono-mac-sdk/external/bockbuild/stage/bin/mono".
  Architecture set to: i386-apple-macosx.
  (lldb) thread list
  Process 2037 stopped
  * thread mono/mono#1: tid = 0x530e96a, 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_507', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    thread mono/mono#2: tid = 0x530e96b, 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
    thread mono/mono#3: tid = 0x530e96c, 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'SGen worker'
    thread mono/mono#4: tid = 0x530e96d, 0x923c7fb6 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Finalizer'
    thread mono/mono#5: tid = 0x530e96e, 0x923cd992 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager'
    thread mono/mono#6: tid = 0x530ea26, 0x923ccace libsystem_kernel.dylib`__select + 10, name = 'tid_5a03'
    thread mono/mono#7: tid = 0x530edf1, 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_4007'
    thread mono/mono#8: tid = 0x530edf2, 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Threadpool worker'
    thread mono/mono#9: tid = 0x530edf3, 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Threadpool worker'
    thread mono/mono#10: tid = 0x530edf4, 0x923ccff2 libsystem_kernel.dylib`__wait4 + 10, name = 'Domain unloader'
  (lldb) thread backtrace all
  * thread mono/mono#1, name = 'tid_507', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    * frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
      frame mono/mono#1: 0x9ae6fd1d libsystem_pthread.dylib`_pthread_cond_wait + 728
      frame mono/mono#2: 0x9ae71bd9 libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 71
      frame mono/mono#3: 0x00361ea9 mono`mono_os_event_wait_multiple + 505
      frame mono/mono#4: 0x00361ca5 mono`mono_os_event_wait_one + 53
      frame mono/mono#5: 0x00376b49 mono`mono_thread_info_wait_one_handle + 41
      frame mono/mono#6: 0x002d51b5 mono`mono_domain_try_unload + 485
      frame mono/mono#7: 0x002d4f6a mono`ves_icall_System_AppDomain_InternalUnload + 90
      frame mono/mono#8: 0x05bf9ee0
      frame mono/mono#9: 0x018ce01d mscorlib.dll.dylib`System_AppDomain_Unload_System_AppDomain + 45
      frame mono/mono#10: 0x05bf9d60
      frame mono/mono#11: 0x05bf9ccc
      frame mono/mono#12: 0x05bf9d04
      frame mono/mono#13: 0x05bf9c90
      frame mono/mono#14: 0x05bf996d
      frame mono/mono#15: 0x02e7d171
      frame mono/mono#16: 0x005c26d4
      frame mono/mono#17: 0x005b6878
      frame mono/mono#18: 0x005b6b7a
      frame mono/mono#19: 0x000c38a8 mono`mono_jit_runtime_invoke + 1592
      frame mono/mono#20: 0x002e43fe mono`do_runtime_invoke + 94
      frame mono/mono#21: 0x002e7de3 mono`do_exec_main_checked + 147
      frame mono/mono#22: 0x002e69a5 mono`mono_runtime_run_main_checked + 69
      frame mono/mono#23: 0x0013b687 mono`mono_jit_exec + 311
      frame mono/mono#24: 0x0013e2b2 mono`mono_main + 10114
      frame mono/mono#25: 0x000b22db mono`main + 2011
      frame mono/mono#26: 0x000b1af5 mono`start + 53
    thread mono/mono#2, name = 'SGen worker'
      frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
      frame mono/mono#1: 0x9ae6fd1d libsystem_pthread.dylib`_pthread_cond_wait + 728
      frame mono/mono#2: 0x9ae71bd9 libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 71
      frame mono/mono#3: 0x0035f0e9 mono`thread_func + 249
      frame mono/mono#4: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#5: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#6: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#3, name = 'SGen worker'
      frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
      frame mono/mono#1: 0x9ae6fd1d libsystem_pthread.dylib`_pthread_cond_wait + 728
      frame mono/mono#2: 0x9ae71bd9 libsystem_pthread.dylib`pthread_cond_wait$UNIX2003 + 71
      frame mono/mono#3: 0x0035f0e9 mono`thread_func + 249
      frame mono/mono#4: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#5: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#6: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#4, name = 'Finalizer'
      frame mono/mono#0: 0x923c7fb6 libsystem_kernel.dylib`semaphore_wait_trap + 10
      frame mono/mono#1: 0x002dbeb6 mono`finalizer_thread + 278
      frame mono/mono#2: 0x002abb6b mono`start_wrapper + 795
      frame mono/mono#3: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#4: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#5: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#5, queue = 'com.apple.libdispatch-manager'
      frame mono/mono#0: 0x923cd992 libsystem_kernel.dylib`kevent64 + 10
      frame mono/mono#1: 0x91b5c899 libdispatch.dylib`_dispatch_mgr_invoke + 238
      frame mono/mono#2: 0x91b5c532 libdispatch.dylib`_dispatch_mgr_thread + 52
    thread mono/mono#6, name = 'tid_5a03'
      frame mono/mono#0: 0x923ccace libsystem_kernel.dylib`__select + 10
      frame mono/mono#1: 0x0036df29 mono`mono_poll + 409
      frame mono/mono#2: 0x002b482f mono`poll_event_wait + 111
      frame mono/mono#3: 0x002b345f mono`selector_thread + 1439
      frame mono/mono#4: 0x002abb6b mono`start_wrapper + 795
      frame mono/mono#5: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#6: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#7: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#7, name = 'tid_4007'
      frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
      frame mono/mono#1: 0x9ae6fd1d libsystem_pthread.dylib`_pthread_cond_wait + 728
      frame mono/mono#2: 0x9ae71c25 libsystem_pthread.dylib`pthread_cond_timedwait$UNIX2003 + 71
      frame mono/mono#3: 0x003760f3 mono`mono_thread_info_sleep + 979
      frame mono/mono#4: 0x002b1a86 mono`monitor_thread + 262
      frame mono/mono#5: 0x002abb6b mono`start_wrapper + 795
      frame mono/mono#6: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#7: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#8: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#8, name = 'Threadpool worker'
      frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
      frame mono/mono#1: 0x9ae6fd1d libsystem_pthread.dylib`_pthread_cond_wait + 728
      frame mono/mono#2: 0x9ae71c25 libsystem_pthread.dylib`pthread_cond_timedwait$UNIX2003 + 71
      frame mono/mono#3: 0x002b12e0 mono`worker_thread + 1024
      frame mono/mono#4: 0x002abb6b mono`start_wrapper + 795
      frame mono/mono#5: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#6: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#7: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#9, name = 'Threadpool worker'
      frame mono/mono#0: 0x923cc7ca libsystem_kernel.dylib`__psynch_cvwait + 10
      frame mono/mono#1: 0x9ae6fd1d libsystem_pthread.dylib`_pthread_cond_wait + 728
      frame mono/mono#2: 0x9ae71c25 libsystem_pthread.dylib`pthread_cond_timedwait$UNIX2003 + 71
      frame mono/mono#3: 0x002b12e0 mono`worker_thread + 1024
      frame mono/mono#4: 0x002abb6b mono`start_wrapper + 795
      frame mono/mono#5: 0x9ae6d5fb libsystem_pthread.dylib`_pthread_body + 144
      frame mono/mono#6: 0x9ae6d485 libsystem_pthread.dylib`_pthread_start + 130
      frame mono/mono#7: 0x9ae72cf2 libsystem_pthread.dylib`thread_start + 34
    thread mono/mono#10, name = 'Domain unloader'
      frame mono/mono#0: 0x923ccff2 libsystem_kernel.dylib`__wait4 + 10
      frame mono/mono#1: 0x940d9ea5 libsystem_c.dylib`waitpid$UNIX2003 + 48
      frame mono/mono#2: 0x0017cba7 mono`mono_handle_native_crash + 519
      frame mono/mono#3: 0x001e2b03 mono`sigabrt_signal_handler + 147
      frame mono/mono#4: 0x920a8deb libsystem_platform.dylib`_sigtramp + 43
  (lldb) detach
  Process 2037 detached
  (lldb) quit

  =================================================================
  Got a SIGABRT while executing native code. This usually indicates
  a fatal error in the mono runtime or one of the native libraries
  used by your application.
  =================================================================
```


Commit migrated from mono/mono@d30c17f
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@lewurm
[amd64] fix tailcall insn size (mono/mono#5483)
1237830 
commit
https://github.com/mono/mono/commit/mono/mono@9a634c1810aad46d30a674f3a97ab263dcd4272e
introduces a regression for
https://github.com/mono/coreclr/blob/mono/tests/src/JIT/Methodical/Invoke/25params/25param1c.il

```
Testing method of 25 parameters, all of int data type, tail.call
mono-sgen(46435,0x7fff9d34b3c0) malloc: *** error for object 0x101045400: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Process 46435 stopped
* thread mono/mono#1, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame mono/mono#0: 0x00007fff945c915f libsystem_malloc.dylib`malloc_error_break
libsystem_malloc.dylib`malloc_error_break:
->  0x7fff945c915f <+0>: pushq  %rbp
    0x7fff945c9160 <+1>: movq   %rsp, %rbp
    0x7fff945c9163 <+4>: nop
    0x7fff945c9164 <+5>: nopl   (%rax)
(lldb) mbt
* thread mono/mono#1
  * frame mono/mono#0: 0x00007fff945c915f libsystem_malloc.dylib`malloc_error_break
    frame mono/mono#1: 0x00007fff945c5e81 libsystem_malloc.dylib`szone_error + 406
    frame mono/mono#2: 0x00007fff945c7925 libsystem_malloc.dylib`small_free_list_remove_ptr_no_clear + 766
    frame mono/mono#3: 0x00007fff945c7cb2 libsystem_malloc.dylib`free_small + 881
    frame mono/mono#4: 0x00000001004d2110 mono-sgen`monoeg_g_free(ptr=0x0000000101083c00) at gmem.c:66
    frame mono/mono#5: 0x0000000100007b64 mono-sgen`mono_codegen(cfg=0x000000010108c800) at mini.c:2300
    frame mono/mono#6: 0x000000010000aedf mono-sgen`mini_method_compile(method=0x0000000100910310, opts=370239999, domain=0x000000010090ebd0, flags=JIT_FLAG_RUN_CCTORS, parts=0, aot_method_index=-1) at mini.c:3829
    frame mono/mono#7: 0x000000010000edd0 mono-sgen`mono_jit_compile_method_inner(method=0x0000000100910310, target_domain=0x000000010090ebd0, opt=370239999, error=0x00007fff5fbfe048) at mini.c:4156
    frame mono/mono#8: 0x000000010001459e mono-sgen`mono_jit_compile_method_with_opt(method=0x0000000100910310, opt=370239999, jit_only=0, error=0x00007fff5fbfe048) at mini-runtime.c:2127
    frame mono/mono#9: 0x0000000100013e6d mono-sgen`mono_jit_compile_method(method=0x0000000100910310, error=0x00007fff5fbfe048) at mini-runtime.c:2173
    frame mono/mono#10: 0x0000000100131eea mono-sgen`common_call_trampoline(regs=0x00007fff5fbfe128, code="H\x8bй\x01", m=0x0000000100910310, vt=0x0000000000000000, vtable_slot=0x0000000000000000, error=0x00007fff5fbfe048) at mini-trampolines.c:704
    frame mono/mono#11: 0x00000001001313b7 mono-sgen`mono_magic_trampoline(regs=0x00007fff5fbfe128, code="H\x8bй\x01", arg=0x0000000100910310, tramp="����\b\x10\x03\x91") at mini-trampolines.c:835
```

turns out we smashed our code buffer.

Also, transform this comparison:

```
if (G_UNLIKELY (offset > (cfg->code_size - max_len - EXTRA_CODE_SPACE))) {

if (G_UNLIKELY ((offset + max_len + EXTRA_CODE_SPACE) > cfg->code_size)) {
```

we deal with unsigned values here, and if `max_len` is bigger then
`cfg->code_size`, we won't resize the buffer.

Commit migrated from mono/mono@79e94c4
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@lewurm
[perfcounters] fix alignment issue on 32bit
a718ee6 
clang fails to properly align 64bit members of the `MonoPerfCounters` struct on
32bit builds:

```
* thread mono/mono#1, name = 'tid_403', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_ARM_DA_ALIGN, address=0x16933124)
    frame mono/mono#0: 0x0066f4b2 mini`mono_atomic_cas_i64(dest=0x16933124, exch=<unavailable>, comp=<unavailable>) at atomic.c:519 [opt]
   516 	gint64
   517 	mono_atomic_cas_i64(volatile gint64 *dest, gint64 exch, gint64 comp)
   518 	{
-> 519 		return  __sync_val_compare_and_swap (dest, comp, exch);
   520 	}
   521
   522 	#elif defined (TARGET_ANDROID)
(lldb) up
frame mono/mono#1: 0x006292ea mini`ves_icall_System_Threading_ThreadPool_NotifyWorkItemQueued [inlined] mono_atomic_inc_i64 at atomic.h:397 [opt]
   394 		do {
   395 			get = *val;
   396 			set = get + 1;
-> 397 		} while (mono_atomic_cas_i64 (val, set, get) != get);
   398 		return set;
   399 	}
   400
(lldb) up
frame mono/mono#2: 0x006292d6 mini`ves_icall_System_Threading_ThreadPool_NotifyWorkItemQueued at threadpool.c:743 [opt]
   740 	ves_icall_System_Threading_ThreadPool_NotifyWorkItemQueued (void)
   741 	{
   742 	#ifndef DISABLE_PERFCOUNTERS
-> 743 		mono_atomic_inc_i64 (&mono_perfcounters->threadpool_workitems);
   744 	#endif
   745 	}
   746
```

Note that the member `threadpool_workitems` is on an unnatural alignment
(`0x16933124`) regarding to its type `gint64`.

related xamarin/xamarin-macios#3826


Commit migrated from mono/mono@a36d08a
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
@jaykrell
[btls] Fixes for windows. (mono/mono#8653)
ac4b5c9 
* [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 mono/mono#1.


Commit migrated from mono/mono@baf58ed
@jfichtner jfichtner mentioned this pull request Sep 7, 2022
Open
@okayabc okayabc mentioned this pull request Jul 21, 2023
Open
@jbatt33 jbatt33 mentioned this pull request Sep 12, 2023
Open
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
1 participant
@rnagy