[Mono-osx] TrySZReverse crashing mono 4.4 (under certain scenario)?

[Phi Le]

I think TrySZReverse is causing a crash in my program. Under certain
conditions (easily repeatable), I think TrySZReverse finish, but my program
will crash soon after the program do some more things. This only a problem
with mono 4.4. The same program doesn't crash with mono 4.0 or 4.2 .
How is TrySZReverse implemented? Usage found here:
https://github.com/mono/mono/blob/d70777a3332af2d630d24adf620c2e548b92b56a/mcs/class/referencesource/mscorlib/system/array.cs#L1605
I am not using TrySZReverse directly; I am using Array.Reverse(Builds, 0,
num);. I tried to do my own array reverse, just like the backup algorithm
in Array.Reverse (line 1609-1629), and the program runs fine.
I can't share this program publicly. The program is using the mobjc
library, a C# Objective-c bridge, so mobjc could be doing things that is
not compatible with mono.
Is this a mono bug? or my program's bug?

Here is what the crashing thread look like with mono 4.4 (64bit).
* thread #1: tid = 0x11b779, 0x00007fff96bb3582
libsystem_kernel.dylib`__wait4 + 10, name = 'tid_50f', queue =
'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff96bb3582 libsystem_kernel.dylib`__wait4 + 10
    frame #1: 0x000000010cb2e721
mono-sgen64`mono_handle_native_sigsegv(signal=<unavailable>,
ctx=<unavailable>, info=<unavailable>) + 433 at mini-exceptions.c:2348 [opt]
    frame #2: 0x000000010cb8453a
mono-sgen64`mono_arch_handle_altstack_exception(sigctx=0x000000010d241f48,
siginfo=<unavailable>, fault_addr=<unavailable>, stack_ovf=0) + 90 at
exceptions-amd64.c:808 [opt]
    frame #3: 0x000000010ca827d8
mono-sgen64`mono_sigsegv_signal_handler(_dummy=<unavailable>,
_info=<unavailable>, context=<unavailable>) + 392 at mini-runtime.c:2888
[opt]
    frame #4: 0x00007fff94b7452a libsystem_platform.dylib`_sigtramp + 26
    frame #5: 0x000000010cc9be59 mono-sgen64`copy_object_no_checks
[inlined] sgen_vtable_get_descriptor(vtable=0x0000000000000000) + 1 at
sgen-client-mono.h:39 [opt]
    frame #6: 0x000000010cc9be58
mono-sgen64`copy_object_no_checks(obj=0x000000010d6b8198,
queue=0x000000010ce05c20) + 24 at sgen-copy-object.h:64 [opt]
    frame #7: 0x000000010cc96ee6 mono-sgen64`drain_gray_stack [inlined]
major_copy_or_mark_object_no_evacuation(obj=<unavailable>) + 33 at
sgen-marksweep-drain-gray-stack.h:91 [opt]
    frame #8: 0x000000010cc96ec5 mono-sgen64`drain_gray_stack [inlined]
major_scan_object_no_evacuation(full_object=<unavailable>,
desc=<unavailable>) + 2221 at sgen-scan-object.h:67 [opt]
    frame #9: 0x000000010cc96618 mono-sgen64`drain_gray_stack [inlined]
drain_gray_stack_no_evacuation + 4516 at
sgen-marksweep-drain-gray-stack.h:278 [opt]
    frame #10: 0x000000010cc95474
mono-sgen64`drain_gray_stack(queue=0x000000010ce05c20) + 84 at
sgen-marksweep.c:1213 [opt]
    frame #11: 0x000000010cc8c848 mono-sgen64`finish_gray_stack [inlined]
sgen_drain_gray_stack + 19 at sgen-gc.c:544 [opt]
    frame #12: 0x000000010cc8c835
mono-sgen64`finish_gray_stack(generation=<unavailable>, ctx=<unavailable>)
+ 69 at sgen-gc.c:1072 [opt]
    frame #13: 0x000000010cc8bf3c
mono-sgen64`major_finish_collection(reason="LOS overflow",
old_next_pin_slot=294, forced=0) + 108 at sgen-gc.c:1924 [opt]
    frame #14: 0x000000010cc89691
mono-sgen64`major_do_collection(reason="LOS overflow", forced=0) + 81 at
sgen-gc.c:2049 [opt]
    frame #15: 0x000000010cc88b10
mono-sgen64`sgen_perform_collection(requested_size=32800,
generation_to_collect=1, reason="LOS overflow", wait_to_finish=0) + 432 at
sgen-gc.c:2266 [opt]
    frame #16: 0x000000010cc90059
mono-sgen64`sgen_los_alloc_large_inner(vtable=0x00007fdd28922da0,
size=32800) + 89 at sgen-los.c:368 [opt]
    frame #17: 0x000000010cc7f179
mono-sgen64`sgen_alloc_obj_nolock(vtable=0x00007fdd28922da0,
size=<unavailable>) + 105 at sgen-alloc.c:199 [opt]
    frame #18: 0x000000010cc7c9db
mono-sgen64`mono_gc_alloc_vector(vtable=0x00007fdd28922da0, size=32800,
max_length=4096) + 123 at sgen-mono.c:1735 [opt]
    frame #19: 0x000000010d1b37a6
    frame #20: 0x000000010ebc4f9f
mscorlib.dll.dylib`System_Collections_Generic_List_1_T_REF__ctor_int + 159
    frame #21: 0x00000001113f620a
    frame #22: 0x000000010f7d1c78
    frame #23: 0x0000000113bcd6ba
    frame #24: 0x000000010ca85800
mono-sgen64`mono_jit_runtime_invoke(method=<unavailable>,
obj=0x000000010d4d9218, params=<unavailable>, exc=<unavailable>) + 1776 at
mini-runtime.c:2578 [opt]
    frame #25: 0x000000010cc45252
mono-sgen64`mono_runtime_invoke(method=0x00007fdd29926748,
obj=0x000000010d4d9218, params=0x00007fff53184f20, exc=0x0000000000000000)
+ 130 at object.c:2897 [opt]
    frame #26: 0x000000010cc4ba52
mono-sgen64`mono_runtime_invoke_array(method=<unavailable>,
obj=<unavailable>, params=<unavailable>, exc=<unavailable>) + 1522 at
object.c:4423 [opt]
    frame #27: 0x000000010cbbc7e1
mono-sgen64`ves_icall_InternalInvoke(method=<unavailable>,
this_arg=<unavailable>, params=<unavailable>, exc=<unavailable>) + 705 at
icall.c:2856 [opt]
    frame #28: 0x000000010f743254
    frame #29: 0x000000010ee4547c
mscorlib.dll.dylib`System_Reflection_MonoCMethod_DoInvoke_object_System_Reflection_BindingFlags_System_Reflection_Binder_object___System_Globalization_CultureInfo
+ 220
    frame #30: 0x000000010ee45607
mscorlib.dll.dylib`System_Reflection_MonoCMethod_Invoke_System_Reflection_BindingFlags_System_Reflection_Binder_object___System_Globalization_CultureInfo
+ 55
    frame #31: 0x000000010ee3c8d0
mscorlib.dll.dylib`System_Reflection_ConstructorInfo_Invoke_object__ + 96
    frame #32: 0x00000001113f78a5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-osx/attachments/20160707/ba122bb6/attachment.html>