Skip to content

[Xamarin.Android.Build.Tasks] Import from monodroid/301e7238 - #5

Merged
jonpryor merged 1 commit into
dotnet:masterfrom
dellis1972:master
Apr 25, 2016
Merged

[Xamarin.Android.Build.Tasks] Import from monodroid/301e7238#5
jonpryor merged 1 commit into
dotnet:masterfrom
dellis1972:master

Conversation

@dellis1972

@dellis1972dellis1972 commented Apr 25, 2016

Copy link
Copy Markdown
Contributor

Added Xamarin.Android.Build.Tasks and its supporting Libraries.
Code has also been updated to make sure of the new libraries in
the Java.Interop repository

Note : Xamarin.Android.Build.Tasks has a compile time code
generation step which generates Profile.g.cs. This file contains
the list of SharedRuntimeAssemblies. If building manually you will
need to make sure that Xamarin.Android.Tools.BootstrapTasks is
built first.

@dellis1972
[Xamarin.Android.Build.Tasks] Import from monodroid/301e7238
59ec488
Added Xamarin.Android.Build.Tasks and its supporting Libraries.
Code has also been updated to make uses of the new libraries in
the Java.Interop repository
Note : Xamarin.Android.Build.Tasks has a compile time code
generation step which generates Profile.g.cs. This file contains
the list of SharedRuntimeAssemblies. If building manually you will
need to make sure that Xamarin.Android.Tools.BootstrapTasks is
built first.
@jonpryor
jonpryor merged commit 45a0818 into dotnet:masterApr 25, 2016
@uwantfriesuwantfries mentioned this pull request Jan 22, 2018
Closed
@nshayanfarnshayanfar mentioned this pull request Jan 24, 2018
Closed
@wouterst79wouterst79 mentioned this pull request Mar 29, 2018
Closed
radical pushed a commit that referenced this pull request May 8, 2018
@jonpryor
[Java.Runtime.Environment] Don't Destroy the JVM by default. (#65)
bee46ef
When `JniRuntime.CreationOptions.DestroyRuntimeOnDispose` is true,
`JavaVM::DestroyJavaVM()` will be invoked when the `JniRuntime`
instance is disposed *or* finalized.
`JreRuntime.CreateJreVM()` would *always* set
`DestroyRuntimeOnDispose` to true, because it called
`JNI_CreateJavaVM()`, so *of course* you'd want to destroy the
Java VM, right?
Which brings us to unit tests. I don't know of any "before all test
fixtures run" and "after all test fixtures run" extension points,
which means:
1. The JVM needs to be created implicitly, "on demand."
2. There's no good way to destroy the JVM created in (1) after all
tests have finished executing.
Which *really* means that the `JreRuntime` instance is *finalized*,
which sets us up for the unholy trifecta of AppDomain unloads,
finalizers, and JVM shutdown:
For unknown reasons, ~randomly, when running the unit tests (e.g.
`make run-tests`), the test runner will *hang*, indefinitely.
Attaching `lldb` and triggering a backtrace shows the unholy trifecta:
Finalization:
thread #4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
...
frame #10: 0x00000001001ccb4a mono64`mono_gc_run_finalize(obj=<unavailable>, data=<unavailable>) + 938 at gc.c:256 [opt]
frame #11: 0x00000001001cdd4a mono64`finalizer_thread [inlined] finalize_domain_objects + 51 at gc.c:681 [opt]
frame #12: 0x00000001001cdd17 mono64`finalizer_thread(unused=<unavailable>) + 295 at gc.c:730 [opt]
JVM destruction:
thread #4: tid = 0x403831, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'tid_1403'
frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
frame #2: 0x000000010ba5bc76 libjvm.dylib`os::PlatformEvent::park() + 192
frame #3: 0x000000010ba38e32 libjvm.dylib`ParkCommon(ParkEvent*, long) + 42
frame #4: 0x000000010ba39708 libjvm.dylib`Monitor::IWait(Thread*, long) + 168
frame #5: 0x000000010ba398f0 libjvm.dylib`Monitor::wait(bool, long, bool) + 246
frame #6: 0x000000010bb3dca2 libjvm.dylib`Threads::destroy_vm() + 80
frame #7: 0x000000010b8fd665 libjvm.dylib`jni_DestroyJavaVM + 254
AppDomain unload:
thread #37: tid = 0x4038fb, 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
frame #0: 0x00007fff9656bdb6 libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x00007fffa04d4728 libsystem_pthread.dylib`_pthread_cond_wait + 767
frame #2: 0x0000000100234a7f mono64`mono_os_cond_timedwait [inlined] mono_os_cond_wait(cond=0x0000000102016e50, mutex=0x0000000102016e10) + 11 at mono-os-mutex.h:105 [opt]
frame #3: 0x0000000100234a74 mono64`mono_os_cond_timedwait(cond=0x0000000102016e50, mutex=0x0000000102016e10, timeout_ms=<unavailable>) + 164 at mono-os-mutex.h:120 [opt]
frame #4: 0x0000000100234828 mono64`_wapi_handle_timedwait_signal_handle(handle=0x0000000000000440, timeout=4294967295, alertable=1, poll=<unavailable>, alerted=0x0000700000a286f4) + 536 at handles.c:1554 [opt]
frame #5: 0x0000000100246370 mono64`wapi_WaitForSingleObjectEx(handle=<unavailable>, timeout=<unavailable>, alertable=<unavailable>) + 592 at wait.c:189 [opt]
frame #6: 0x00000001001c832e mono64`mono_domain_try_unload [inlined] guarded_wait(timeout=4294967295, alertable=1) + 30 at appdomain.c:2390 [opt]
frame #7: 0x00000001001c8310 mono64`mono_domain_try_unload(domain=0x000000010127ccb0, exc=0x0000700000a287a0) + 416 at appdomain.c:2482 [opt]
frame #8: 0x00000001001c7db2 mono64`ves_icall_System_AppDomain_InternalUnload [inlined] mono_domain_unload(domain=<unavailable>) + 20 at appdomain.c:2379 [opt]
frame #9: 0x00000001001c7d9e mono64`ves_icall_System_AppDomain_InternalUnload(domain_id=<unavailable>) + 46 at appdomain.c:2039 [opt]
This randomly results in deadlock, and hung Jenkins bots.
Fix this behavior by altering `JreRuntime.CreateJreVM()` to *not*
override the value of
`JniRuntime.CreationOptions.DestroyRuntimeOnDispose`. This allows the
constructor of the `JreRuntime` instance to decide whether or not the
JVM is destroyed.
In the case of TestJVM, we *don't* want to destroy the JVM.
This prevents the JVM from being destroyed, which in turn prevents the
hang during process shutdown.
@huy2368huy2368 mentioned this pull request May 11, 2018
Closed
grendello added a commit to grendello/xamarin-android that referenced this pull request Jul 18, 2018
@grendello
Fix ILRepack target on Linux
798de2e
Xamarin.Android uses the ILRepack
task (https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task/) to repack/merge
the `Xamarin.Android.Build.Tasks` assembly, a step that is performed after the
`Xamarin.Android.Build.Tasks` project build completes. The step takes the
project's output assembly and several other dependencies and merges them into
one, replacing the original output assembly. For the majority of time it works
flawlessly, however the scenario described below causes a Mono runtime
crash (similar to this one mono/mono#9613, although
not identical).
The crash causes aren't yet know in every detail, but the high level overview of
the issue is as follows. Mono runtime uses the `mmap(2)` system call on Unix to
map the on-disk image of the assembly into memory. The mmapped area is used
whenever the same assembly is loaded (e.g. via `Assembly.LoadFrom`) into the
application to save time and memory. The memory is mapped as private which means
that anything written to the mapped area by the Mono process is effectively
discarded, that is not reflected in the file on disk. The protection, however,
doesn't work in the other direction - when an external process (or even the same
Mono process) writes to the file that was mmapped. Unfortunately, the OS kernel
behavior in such instance is left undefined by the POSIX standard - the kernel
can choose to reflect the on-disk change in the mapping or ignore it. On macOS
the write is ignored, on Linux, however, the write leads either to the SIGBUS
signal being sent to the process or corruption to the mmapped memory
area (details of how this happens are, as of yet, unknown - it's just a theory
at this point). The problem occurs in our case when the `ILRepacker` task
overwrites the `Xamarin.Android.Build.Tasks.dll` assembly with its
merged/repackaged form and that, somehow, corrupts Mono runtime's memory mapping
of that assembly, eventually leading to a segfault:
#0 0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
#2 0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
#3 0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
dotnet#4 0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
dotnet#5 <signal handler called>
dotnet#6 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
dotnet#7 0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
dotnet#8 0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
dotnet#9 0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
dotnet#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
dotnet#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
dotnet#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
dotnet#13 0x00000000412f4007 in ?? ()
dotnet#14 0x00007f97440e1918 in ?? ()
dotnet#15 0x00007f9749bd1800 in ?? ()
dotnet#16 0x00000000e36e75af in ?? ()
dotnet#17 0x00007f974434fda8 in ?? ()
dotnet#18 0x00007f9749bd18e0 in ?? ()
dotnet#19 0x00007f96e0002820 in ?? ()
dotnet#20 0x00007f9712164160 in ?? ()
dotnet#21 0x00007f9712164010 in ?? ()
dotnet#22 0x0000000000000000 in ?? ()
The crash occurs in frame 7, because the `r` parameter (an instance of the
`MonoAssembly` structure) contains pointers that used to point to valid places
in the `Xamarin.Android.Build.Tasks` assembbly's mmaped area, but now point to
garbage data. One of those corrupted pointers is the ASCII assembly name - which
is used by the function in frame 7.
The situation can be detected by the runtime by using advisory locks and
reporting the attempt to overwrite the mmapped area, however a fix would require
creating a copy of all the assembly's in-memory data before the write is allowed
and that might be too expensive. None of those measures are currently
implemented by Mono (and it isn't sure if any of them will ever be implemented).
The crash this commit fixes occurs in a very specific scenario - when building
the `OpenTK.csproj` project *directly* (that is passing it as parameter to
`msbuild`), which causes a the `Xamarin.Android.Build.Tasks` assembly to be
loaded for use in the `<UsingTask/>` msbuild statement, but at the same time
`OpenTK.csproj` references the `Xamarin.Android.Build.Tasks` *project* which
causes the ILRepacker task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.
The fix, courtesy of @jonpryor, is to make the ILRepacker target not run every
time but only whenver the assembly has to be re-packed because it has just been
rebuilt.
grendello added a commit to grendello/xamarin-android that referenced this pull request Jul 19, 2018
@grendello
Fix ILRepack target on Linux
77959fc
Xamarin.Android uses the ILRepack
task (https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task/) to repack/merge
the `Xamarin.Android.Build.Tasks` assembly, a step that is performed after the
`Xamarin.Android.Build.Tasks` project build completes. The step takes the
project's output assembly and several other dependencies and merges them into
one, replacing the original output assembly. For the majority of time it works
flawlessly, however the scenario described below causes a Mono runtime
crash (similar to this one mono/mono#9613, although
not identical).
The crash causes aren't yet know in every detail, but the high level overview of
the issue is as follows. Mono runtime uses the `mmap(2)` system call on Unix to
map the on-disk image of the assembly into memory. The mmapped area is used
whenever the same assembly is loaded (e.g. via `Assembly.LoadFrom`) into the
application to save time and memory. The memory is mapped as private which means
that anything written to the mapped area by the Mono process is effectively
discarded, that is not reflected in the file on disk. The protection, however,
doesn't work in the other direction - when an external process (or even the same
Mono process) writes to the file that was mmapped. Unfortunately, the OS kernel
behavior in such instance is left undefined by the POSIX standard - the kernel
can choose to reflect the on-disk change in the mapping or ignore it. On macOS
the write is ignored, on Linux, however, the write leads either to the SIGBUS
signal being sent to the process or corruption to the mmapped memory
area (details of how this happens are, as of yet, unknown - it's just a theory
at this point). The problem occurs in our case when the `ILRepacker` task
overwrites the `Xamarin.Android.Build.Tasks.dll` assembly with its
merged/repackaged form and that, somehow, corrupts Mono runtime's memory mapping
of that assembly, eventually leading to a segfault:
#0 0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
#2 0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
#3 0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
dotnet#4 0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
dotnet#5 <signal handler called>
dotnet#6 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
dotnet#7 0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
dotnet#8 0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
dotnet#9 0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
dotnet#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
dotnet#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
dotnet#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
dotnet#13 0x00000000412f4007 in ?? ()
dotnet#14 0x00007f97440e1918 in ?? ()
dotnet#15 0x00007f9749bd1800 in ?? ()
dotnet#16 0x00000000e36e75af in ?? ()
dotnet#17 0x00007f974434fda8 in ?? ()
dotnet#18 0x00007f9749bd18e0 in ?? ()
dotnet#19 0x00007f96e0002820 in ?? ()
dotnet#20 0x00007f9712164160 in ?? ()
dotnet#21 0x00007f9712164010 in ?? ()
dotnet#22 0x0000000000000000 in ?? ()
The accompanying managed stacktrace looks as follows:
Stacktrace:
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539
at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571
at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes.ScanAssemblyForPublicTypes () [0x00007] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes/<>c__DisplayClass8_0.<GetLoadedTypeByTypeName>b__0 (string) [0x000b4] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Collections.Concurrent.ConcurrentDictionary`2<TKey_REF, TValue_REF>.GetOrAdd (TKey_REF,System.Func`2<TKey_REF, TValue_REF>) [0x00034] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes.GetLoadedTypeByTypeName (string) [0x0003c] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Shared.TypeLoader.GetLoadedType (System.Collections.Concurrent.ConcurrentDictionary`2<System.Func`3<System.Type, object, bool>, System.Collections.Concurrent.ConcurrentDictionary`2<Microsoft.Build.Shared.AssemblyLoadInfo, Microsoft.Build.Shared.TypeLoader/AssemblyInfoToLoadedTypes>>,string,Microsoft.Build.Shared.AssemblyLoadInfo) [0x00042] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Shared.TypeLoader.Load (string,Microsoft.Build.Shared.AssemblyLoadInfo) [0x00008] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.AssemblyTaskFactory.InitializeFactory (Microsoft.Build.Shared.AssemblyLoadInfo,string,System.Collections.Generic.IDictionary`2<string, Microsoft.Build.Framework.TaskPropertyInfo>,string,System.Collections.Generic.IDictionary`2<string, string>,bool,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation,string) [0x00058] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Execution.TaskRegistry/RegisteredTaskRecord.GetTaskFactory (Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation,string) [0x000b8] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Execution.TaskRegistry/RegisteredTaskRecord.CanTaskBeCreatedByFactory (string,string,System.Collections.Generic.IDictionary`2<string, string>,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation) [0x0003b] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Execution.TaskRegistry.GetMatchingRegistration (string,System.Collections.Generic.List`1<Microsoft.Build.Execution.TaskRegistry/RegisteredTaskRecord>,string,System.Collections.Generic.IDictionary`2<string, string>,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation) [0x0001a] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Execution.TaskRegistry.GetTaskRegistrationRecord (string,string,System.Collections.Generic.IDictionary`2<string, string>,bool,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation,bool&) [0x00169] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.Execution.TaskRegistry.GetRegisteredTask (string,string,System.Collections.Generic.IDictionary`2<string, string>,bool,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.Construction.ElementLocation) [0x00010] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TaskExecutionHost.FindTaskInRegistry (System.Collections.Generic.IDictionary`2<string, string>) [0x00038] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.FindTask (System.Collections.Generic.IDictionary`2<string, string>) [0x0000b] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19.MoveNext () [0x0011e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19> (Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket (Microsoft.Build.BackEnd.TaskHost,Microsoft.Build.BackEnd.ItemBucket,Microsoft.Build.BackEnd.TaskExecutionMode,System.Collections.Generic.Dictionary`2<string, string>) [0x00048] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18.MoveNext () [0x0016a] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18> (Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask (Microsoft.Build.BackEnd.TaskExecutionMode,Microsoft.Build.BackEnd.Lookup) [0x00037] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13.MoveNext () [0x00193] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13> (Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask (Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.BackEnd.BuildRequestEntry,Microsoft.Build.BackEnd.ITargetBuilderCallback,Microsoft.Build.Execution.ProjectTargetInstanceChild,Microsoft.Build.BackEnd.TaskExecutionMode,Microsoft.Build.BackEnd.Lookup,Microsoft.Build.BackEnd.Lookup,System.Threading.CancellationToken) [0x0006c] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52.MoveNext () [0x00091] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.BackEnd.WorkUnitResult>.Start<Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52> (Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:471
at Microsoft.Build.BackEnd.TargetEntry.ProcessBucket (Microsoft.Build.BackEnd.ITaskBuilder,Microsoft.Build.BackEnd.Logging.TargetLoggingContext,Microsoft.Build.BackEnd.TaskExecutionMode,Microsoft.Build.BackEnd.Lookup,Microsoft.Build.BackEnd.Lookup) [0x00051] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45.MoveNext () [0x002bb] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start<Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45> (Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45&) [0x0002c] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:316
at Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget (Microsoft.Build.BackEnd.ITaskBuilder,Microsoft.Build.BackEnd.BuildRequestEntry,Microsoft.Build.BackEnd.Logging.ProjectLoggingContext,System.Threading.CancellationToken) [0x00048] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at Microsoft.Build.BackEnd.TargetBuilder/<ProcessTargetStack>d__21.MoveNext () [0x003a5] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<System.Threading.Tasks.VoidTaskResult>.TrySetResult (System.Threading.Tasks.VoidTaskResult) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<System.Threading.Tasks.VoidTaskResult>.SetResult (System.Threading.Tasks.VoidTaskResult) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<System.Threading.Tasks.VoidTaskResult>.SetResult (System.Threading.Tasks.Task`1<System.Threading.Tasks.VoidTaskResult>) [0x00010] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:636
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.SetResult () [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:378
at Microsoft.Build.BackEnd.TargetEntry/<ExecuteTarget>d__45.MoveNext () [0x00720] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.TargetEntry/<ProcessBucket>d__52.MoveNext () [0x001d5] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__13.MoveNext () [0x0021e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteTask>d__18.MoveNext () [0x002be] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteBucket>d__19.MoveNext () [0x003e5] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<InitializeAndExecuteTask>d__24.MoveNext () [0x0012d] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.TaskBuilder/<ExecuteInstantiatedTask>d__26.MoveNext () [0x0065e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<bool>.TrySetResult (bool) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.SetResult (bool) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
at Microsoft.Build.BackEnd.MSBuild/<ExecuteInternal>d__76.MoveNext () [0x004dd] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<bool>.TrySetResult (bool) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.SetResult (bool) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
at Microsoft.Build.BackEnd.MSBuild/<BuildProjectsInParallel>d__77.MoveNext () [0x0014a] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<bool>.TrySetResult (bool) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<bool>.SetResult (bool) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
at Microsoft.Build.BackEnd.MSBuild/<ExecuteTargets>d__80.MoveNext () [0x00713] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<Microsoft.Build.Framework.BuildEngineResult>.TrySetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.Framework.BuildEngineResult>.SetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
at Microsoft.Build.BackEnd.TaskHost/<InternalBuildProjects>d__49.MoveNext () [0x0025c] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<Microsoft.Build.Framework.BuildEngineResult>.TrySetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<Microsoft.Build.Framework.BuildEngineResult>.SetResult (Microsoft.Build.Framework.BuildEngineResult) [0x0003d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:608
at Microsoft.Build.BackEnd.TaskHost/<BuildProjectFilesInParallelAsync>d__53.MoveNext () [0x004fb] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.RequestBuilder/<BuildProjects>d__33.MoveNext () [0x00263] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<TResult_REF>.TrySetResult (TResult_REF) [0x0004f] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1<TResult_REF>.SetResult (TResult_REF) [0x0003d] in <79002cfb0e6e431d8465d6dcea08995e>:0
at Microsoft.Build.BackEnd.RequestBuilder/<StartNewBuildRequests>d__51.MoveNext () [0x0020e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.InvokeMoveNext (object) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1094
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Runtime.CompilerServices.AsyncMethodBuilderCore/MoveNextRunner.Run () [0x00024] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1075
at System.Threading.Tasks.AwaitTaskContinuation.RunOrScheduleAction (System.Action,bool,System.Threading.Tasks.Task&) [0x0001a] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:680
at System.Threading.Tasks.Task.FinishContinuations () [0x00052] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:3198
at System.Threading.Tasks.Task.FinishStageThree () [0x0003c] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:2247
at System.Threading.Tasks.Task`1<int>.TrySetResult (int) [0x0004f] in /home/grendel/vc/mono/mono/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/Future.cs:433
at System.Threading.Tasks.TaskCompletionSource`1<int>.TrySetResult (int) [0x00000] in /home/grendel/vc/mono/mono/external/corefx/src/Common/src/CoreLib/System/Threading/Tasks/TaskCompletionSource.cs:274
at Microsoft.Build.Shared.AwaitExtensions/<>c__DisplayClass7_2.<ToTask>b__0 (object,bool) [0x00038] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
at System.Threading.RegisteredWaitHandle.DoCallBack (object) [0x00008] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Threading/RegisteredWaitHandle.cs:103
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context (object) [0x0000d] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1308
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00071] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:961
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:908
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00021] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1285
at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00074] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:858
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in /home/grendel/vc/mono/mono/mcs/class/referencesource/mscorlib/system/threading/threadpool.cs:1213
at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) [0x0001f] in <79002cfb0e6e431d8465d6dcea08995e>:0
The crash occurs in frame 7, because the `r` parameter (an instance of the
`MonoAssembly` structure) contains pointers that used to point to valid places
in the `Xamarin.Android.Build.Tasks` assembbly's mmaped area, but now point to
garbage data. One of those corrupted pointers is the ASCII assembly name - which
is used by the function in frame 7.
The situation can be detected by the runtime by using advisory locks and
reporting the attempt to overwrite the mmapped area, however a fix would require
creating a copy of all the assembly's in-memory data before the write is allowed
and that might be too expensive. None of those measures are currently
implemented by Mono (and it isn't sure if any of them will ever be implemented).
The crash this commit fixes occurs in a very specific scenario - when building
the `OpenTK.csproj` project *directly* (that is passing it as parameter to
`msbuild`), which causes a the `Xamarin.Android.Build.Tasks` assembly to be
loaded for use in the `<UsingTask/>` msbuild statement, but at the same time
`OpenTK.csproj` references the `Xamarin.Android.Build.Tasks` *project* which
causes the ILRepacker task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.
The fix, courtesy of @jonpryor, is to make the ILRepacker target not run every
time but only whenver the assembly has to be re-packed because it has just been
rebuilt.
jonpryor pushed a commit that referenced this pull request Jul 19, 2018
@grendello@jonpryor
[Xamarin.Android.Build.Tasks] Fix ILRepack target rebuilds (#1979)
8d33ea7
Xamarin.Android uses the [ILRepack task][0] to repack/merge the
`Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is
performed after the `Xamarin.Android.Build.Tasks.csproj` project's
`Build` target completes. The step takes the project's output
assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other
dependencies, then merges them into one, *replacing* the original
output assembly.
The majority of time it works flawlessly, however when building the
`monodroid` repo we observe a Mono runtime crash, similar-but-not-
identical to [mono issue 9613][m9613]. Not all details are
understood, but the high level overview of the issue is as follows:
Mono runtime uses the **mmap**(2) system call on Unix to map the
on-disk image of the assembly into memory. The `mmapp`ed area is
used whenever the same assembly is loaded (e.g.
`Assembly.LoadFrom()`) into the application to save time and memory.
The memory is mapped as private which means that anything written to
the mapped area by the Mono process is effectively discarded, that is
not reflected in the file on disk. The protection, however, doesn't
work in the other direction: when an external process (or even the
same Mono process!) writes to the file that was `mmapp`ed.
Unfortunately, the OS kernel behavior in such instance is left
undefined by the POSIX standard: the kernel can choose to reflect the
on-disk change in the mapping or ignore it. On macOS the write is
ignored; on Linux, the write leads either to the `SIGBUS` signal
being sent to the process or corruption to the `mmap`ped memory area
(details of how this happens are, as of yet, unknown; it's just a
theory at this point). The problem occurs in our case when the
`<ILRepacker/>` task overwrites the `Xamarin.Android.Build.Tasks.dll`
assembly with its merged/repackaged form and that, somehow, corrupts
Mono runtime's memory mapping of that assembly, eventually crashing:
## native crash
#0 0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
#2 0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
#3 0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
#4 0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
#5 <signal handler called>
#6 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
#7 0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
#8 0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
#9 0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
...
## managed stacktrace
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539
at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571
at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
...
The crash occurs in frame 7, because the `r` parameter (an instance
of the `MonoAssembly` structure) contains pointers that used to point
to valid places in the `Xamarin.Android.Build.Tasks.dll`s `mmap`ed
area, but now point to garbage data. One of those corrupted pointers
is the ASCII assembly name - which is used by the function in frame 7.
The crash this commit fixes occurs in a very specific scenario: when
building the `OpenTK.csproj` project *directly*
(e.g. `msbuild OpenTK.csproj`), which causes the
`Xamarin.Android.Build.Tasks.dll` assembly to be loaded for use in
the `<UsingTask/>` MSBuild statement, but at the same time `OpenTK.csproj` has a `@(ProjectReference)` to
`Xamarin.Android.Build.Tasks.csproj`, which caused the
`<ILRepacker/>` task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.
The fix, courtesy of @jonpryor, is to make the `ILRepacker` target
not run every time but only whenever the assembly has to be re-packed
because it has just been rebuilt.
This also improves rebuild times.
[0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task
[m9613]: mono/mono#9613
jonpryor pushed a commit that referenced this pull request Aug 3, 2018
@grendello@jonpryor
[Xamarin.Android.Build.Tasks] Fix ILRepack target rebuilds (#1979)
9cd31f5
Xamarin.Android uses the [ILRepack task][0] to repack/merge the
`Xamarin.Android.Build.Tasks.dll` assembly (610ade7), a step that is
performed after the `Xamarin.Android.Build.Tasks.csproj` project's
`Build` target completes. The step takes the project's output
assembly -- `Xamarin.Android.Build.Tasks.dll` -- and several other
dependencies, then merges them into one, *replacing* the original
output assembly.
The majority of time it works flawlessly, however when building the
`monodroid` repo we observe a Mono runtime crash, similar-but-not-
identical to [mono issue 9613][m9613]. Not all details are
understood, but the high level overview of the issue is as follows:
Mono runtime uses the **mmap**(2) system call on Unix to map the
on-disk image of the assembly into memory. The `mmapp`ed area is
used whenever the same assembly is loaded (e.g.
`Assembly.LoadFrom()`) into the application to save time and memory.
The memory is mapped as private which means that anything written to
the mapped area by the Mono process is effectively discarded, that is
not reflected in the file on disk. The protection, however, doesn't
work in the other direction: when an external process (or even the
same Mono process!) writes to the file that was `mmapp`ed.
Unfortunately, the OS kernel behavior in such instance is left
undefined by the POSIX standard: the kernel can choose to reflect the
on-disk change in the mapping or ignore it. On macOS the write is
ignored; on Linux, the write leads either to the `SIGBUS` signal
being sent to the process or corruption to the `mmap`ped memory area
(details of how this happens are, as of yet, unknown; it's just a
theory at this point). The problem occurs in our case when the
`<ILRepacker/>` task overwrites the `Xamarin.Android.Build.Tasks.dll`
assembly with its merged/repackaged form and that, somehow, corrupts
Mono runtime's memory mapping of that assembly, eventually crashing:
## native crash
#0 0x00007f974fd1b23a in __waitpid (pid=pid@entry=120561, stat_loc=stat_loc@entry=0x7f9712162b9c, options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1 0x000055b471f36c96 in dump_native_stacktrace (ctx=0x7f97121637c0, signal=0x55b472147cd3 "SIGSEGV") at mini-posix.c:719
#2 0x000055b471f36df2 in mono_dump_native_crash_info (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-posix.c:742
#3 0x000055b471ecc620 in mono_handle_native_crash (signal=signal@entry=0x55b472147cd3 "SIGSEGV", ctx=ctx@entry=0x7f97121637c0, info=info@entry=0x7f97121638f0) at mini-exceptions.c:2938
#4 0x000055b471e4c82c in mono_sigsegv_signal_handler (_dummy=7, _info=0x7f97121638f0, context=0x7f97121637c0) at mini-runtime.c:3441
#5 <signal handler called>
#6 __strcasecmp_l_avx () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:199
#7 0x000055b471fb2105 in mono_assembly_names_equal_flags (l=l@entry=0x7f96e0004370, r=r@entry=0x7f97307edb60, flags=flags@entry=MONO_ANAME_EQ_IGNORE_CASE) at assembly.c:663
#8 0x000055b471fa7baf in mono_domain_assembly_search (aname=0x7f96e0004370, user_data=0x0) at appdomain.c:2242
#9 0x000055b471fb10f7 in mono_assembly_invoke_search_hook_internal (aname=aname@entry=0x7f96e0004370, requesting=requesting@entry=0x0, refonly=0, postload=postload@entry=0) at assembly.c:1755
#10 0x000055b471fb4526 in mono_assembly_load_from_predicate (image=image@entry=0x7f96e001aae0, fname=fname@entry=0x7f96e000bc50 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=asmctx@entry=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2638
#11 0x000055b471fb635c in mono_assembly_open_predicate (filename=<optimized out>, filename@entry=0x7f96e000ae40 "/home/grendel/vc/xamarin/monodroid/monodroid/external/xamarin-android/src/Xamarin.Android.Build.Tasks/../../packages/ILRepack.Lib.MSBuild.Task.2.0.15.4/build/ILRepack.Lib.MSBuild.Task.dll", asmctx=MONO_ASMCTX_LOADFROM, predicate=predicate@entry=0x0, user_data=user_data@entry=0x0, status=status@entry=0x7f9712163fd4) at assembly.c:2206
#12 0x000055b471fabd42 in ves_icall_System_Reflection_Assembly_LoadFrom (fname=..., refOnly=<optimized out>, error=0x7f9712164050) at appdomain.c:2272
...
## managed stacktrace
at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom (string,bool) [0x0001b] in <79002cfb0e6e431d8465d6dcea08995e>:0
at System.Reflection.Assembly.LoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:539
at System.Reflection.Assembly.UnsafeLoadFrom (string) [0x00000] in /home/grendel/vc/mono/mono/mcs/class/corlib/System.Reflection/Assembly.cs:571
at Microsoft.Build.Shared.TypeLoader.LoadAssembly (Microsoft.Build.Shared.AssemblyLoadInfo) [0x0001e] in <bdc5207a22bb42ae9fe3f3d07e82871e>:0
...
The crash occurs in frame 7, because the `r` parameter (an instance
of the `MonoAssembly` structure) contains pointers that used to point
to valid places in the `Xamarin.Android.Build.Tasks.dll`s `mmap`ed
area, but now point to garbage data. One of those corrupted pointers
is the ASCII assembly name - which is used by the function in frame 7.
The crash this commit fixes occurs in a very specific scenario: when
building the `OpenTK.csproj` project *directly*
(e.g. `msbuild OpenTK.csproj`), which causes the
`Xamarin.Android.Build.Tasks.dll` assembly to be loaded for use in
the `<UsingTask/>` MSBuild statement, but at the same time `OpenTK.csproj` has a `@(ProjectReference)` to
`Xamarin.Android.Build.Tasks.csproj`, which caused the
`<ILRepacker/>` task to run unconditionally, attempting to repack the
assemblies again and leading to the crash described above.
The fix, courtesy of @jonpryor, is to make the `ILRepacker` target
not run every time but only whenever the assembly has to be re-packed
because it has just been rebuilt.
This also improves rebuild times.
[0]: https://www.nuget.org/packages/ILRepack.Lib.MSBuild.Task
[m9613]: mono/mono#9613
lewurm added a commit to lewurm/xamarin-android that referenced this pull request Nov 20, 2018
@lewurm
emtpy commit to retrigger builddotnet#5
5afdb59
dellis1972 referenced this pull request in dellis1972/xamarin-android Feb 5, 2019
@dellis1972
[monodroid] Fix runtime crash when using fastdev typemaps
6fd14c9
When using fastdev typemaps we get the following error
```
01-31 10:57:34.336 5802 5802 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5802 (haredandroidios), pid 5802 (haredandroidios)
01-31 10:57:34.358 5829 5829 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
01-31 10:57:34.358 1685 1685 I /system/bin/tombstoned: received crash request for pid 5802
01-31 10:57:34.359 5829 5829 I crash_dump32: performing dump of process 5802 (target tid = 5802)
01-31 10:57:34.363 5829 5829 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-31 10:57:34.363 5829 5829 F DEBUG : Build fingerprint: 'Android/sdk_phone_x86/generic_x86:9/PSR1.180720.012/4923214:userdebug/test-keys'
01-31 10:57:34.363 5829 5829 F DEBUG : Revision: '0'
01-31 10:57:34.363 5829 5829 F DEBUG : ABI: 'x86'
01-31 10:57:34.363 5829 5829 F DEBUG : pid: 5802, tid: 5802, name: haredandroidios >>> com.xamarin.blankformssharedandroidios <<<
01-31 10:57:34.363 5829 5829 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
01-31 10:57:34.363 5829 5829 F DEBUG : Cause: null pointer dereference
01-31 10:57:34.363 5829 5829 F DEBUG : eax 00000000 ebx e6b2e754 ecx 00000000 edx 00000000
01-31 10:57:34.363 5829 5829 F DEBUG : edi e0cc58f0 esi 00000000
01-31 10:57:34.363 5829 5829 F DEBUG : ebp ffd85ff8 esp ffd85fcc eip e6a60532
01-31 10:57:34.459 5829 5829 F DEBUG :
01-31 10:57:34.459 5829 5829 F DEBUG : backtrace:
01-31 10:57:34.459 5829 5829 F DEBUG : #00 pc 0001e532 /system/lib/libc.so (strlen+18)
01-31 10:57:34.459 5829 5829 F DEBUG : #1 pc 00075952 /system/lib/libc.so (strdup+34)
01-31 10:57:34.459 5829 5829 F DEBUG : #2 pc 0000f6ab /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::add_type_mapping(xamarin::android::internal::TypeMappingInfo**, char const*, char const*, char const*)+667)
01-31 10:57:34.459 5829 5829 F DEBUG : #3 pc 00010ed7 /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::try_load_typemaps_from_directory(char const*)+871)
01-31 10:57:34.459 5829 5829 F DEBUG : #4 pc 000233b8 /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (gather_bundled_assemblies(_JNIEnv*, xamarin::android::jstring_array_wrapper&, bool, int*)+248)
01-31 10:57:34.459 5829 5829 F DEBUG : #5 pc 000229c6 /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jstring*, _jobject*, bool)+166)
01-31 10:57:34.459 5829 5829 F DEBUG : #6 pc 0001f20c /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_and_initialize_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jobjectArray*, _jobject*, bool)+204)
01-31 10:57:34.460 5829 5829 F DEBUG : #7 pc 0001c7af /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (Java_mono_android_Runtime_init+4255)
```
The was down to the `try_load_typemaps_from_directory` passing a
`nullptr` to the `add_type_mapping` method. This method was
calling `strdup`, which does NOT like `nullptr`.
Since the `source_entry` argument is only used for logging we
migth as well create a constant string with a value of
`.__override__` so that if there is a problem we can see
from the logs this was a fastdev issue.
jonpryor pushed a commit that referenced this pull request Feb 5, 2019
@dellis1972@jonpryor
[monodroid] Fix runtime crash when using fastdev typemaps (#2696)
dfd7473
When using fastdev typemaps files we get the following error:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 5802 (haredandroidios), pid 5802 (haredandroidios)
I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 5802
I crash_dump32: performing dump of process 5802 (target tid = 5802)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86/generic_x86:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86'
F DEBUG : pid: 5802, tid: 5802, name: haredandroidios >>> com.xamarin.blankformssharedandroidios <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
F DEBUG : Cause: null pointer dereference
F DEBUG : eax 00000000 ebx e6b2e754 ecx 00000000 edx 00000000
F DEBUG : edi e0cc58f0 esi 00000000
F DEBUG : ebp ffd85ff8 esp ffd85fcc eip e6a60532
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0001e532 /system/lib/libc.so (strlen+18)
F DEBUG : #1 pc 00075952 /system/lib/libc.so (strdup+34)
F DEBUG : #2 pc 0000f6ab /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::add_type_mapping(xamarin::android::internal::TypeMappingInfo**, char const*, char const*, char const*)+667)
F DEBUG : #3 pc 00010ed7 /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::try_load_typemaps_from_directory(char const*)+871)
F DEBUG : #4 pc 000233b8 /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (gather_bundled_assemblies(_JNIEnv*, xamarin::android::jstring_array_wrapper&, bool, int*)+248)
F DEBUG : #5 pc 000229c6 /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jstring*, _jobject*, bool)+166)
F DEBUG : #6 pc 0001f20c /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (create_and_initialize_domain(_JNIEnv*, _jclass*, xamarin::android::jstring_array_wrapper&, _jobjectArray*, _jobject*, bool)+204)
F DEBUG : #7 pc 0001c7af /data/app/com.xamarin.blankformssharedandroidios-nCq7hL5Bz-TYILJl3W97zw==/lib/x86/libmonodroid.so (Java_mono_android_Runtime_init+4255)
The was down to the `try_load_typemaps_from_directory()` passing a
`nullptr` to the `add_type_mapping()` method. This method was
calling **strdup**(3), which does NOT like `nullptr`.
Since the `source_entry` argument is only used for logging we might
as well create a constant string with a value of `.__override__` so
that if there is a problem we can see from the logs this was a
fastdev issue.
@clintonrocksmithclintonrocksmith mentioned this pull request Apr 9, 2019
Closed
@elaccaelacca mentioned this pull request May 9, 2019
Closed
@daniels7daniels7 mentioned this pull request Nov 9, 2019
Closed
@jhakulinjhakulin mentioned this pull request Dec 4, 2019
Closed
@acaliaroacaliaro mentioned this pull request Mar 20, 2020
Closed
grendello added a commit to grendello/xamarin-android that referenced this pull request May 11, 2020
@grendello
[typemaps] Fix a log statement which may lead to segfault when used
e24a4ab
Fixes: dotnet#4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug` added in a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : dotnet#4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : dotnet#5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : dotnet#6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : dotnet#7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.
jonpryor pushed a commit that referenced this pull request May 11, 2020
@grendello
[typemaps] Fix a log statement which may lead to segfault when used (#…
93f9d66
…4673)
Fixes: #4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug` added iFixes: #4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug()` added in a017561 may
lead to a segfault when `assembly` log category and `debug` log level
are enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : #4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : #5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : #6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : #7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.n a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : #4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : #5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : #6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : #7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.
jonpryor pushed a commit that referenced this pull request May 12, 2020
@grendello@jonpryor
[typemaps] Fix a log statement which may lead to segfault when used (#…
be51423
…4673)
Fixes: #4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug` added iFixes: #4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug()` added in a017561 may
lead to a segfault when `assembly` log category and `debug` log level
are enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : #4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : #5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : #6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : #7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.n a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : #4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : #5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : #6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : #7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.
jonpryor pushed a commit that referenced this pull request May 12, 2020
@grendello@jonpryor
[typemaps] Fix a log statement which may lead to segfault when used (#…
5443251
…4673)
Fixes: #4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug` added iFixes: #4596
Context: a017561
Context: https://gist.github.com/pjcollins/87762e81f1f3c7e8b821356e4612eecf
A missing parameter in a call to `log_debug()` added in a017561 may
lead to a segfault when `assembly` log category and `debug` log level
are enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : #4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : #5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : #6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : #7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.n a017561 may lead
to a segfault when `assembly` log category and `debug` log level are
enabled:
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3 in tid 922 (DrawableTinting), pid 922 (DrawableTinting)
I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone
I /system/bin/tombstoned: received crash request for pid 922
I crash_dump64: performing dump of process 922 (target tid = 922)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'Android/sdk_phone_x86_64/generic_x86_64:9/PSR1.180720.012/4923214:userdebug/test-keys'
F DEBUG : Revision: '0'
F DEBUG : ABI: 'x86_64'
F DEBUG : pid: 922, tid: 922, name: DrawableTinting >>> com.xamarin.DrawableTinting <<<
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3
F DEBUG : Cause: null pointer dereference
F DEBUG : rax 0000000000000000 rbx 00007ffed3c283c0 rcx 0000000000000003 rdx 0000000000000002
F DEBUG : r8 00007ffed3c283c0 r9 00000000ffffffff r10 00007ffed3c283d0 r11 00007ffed3c28824
F DEBUG : r12 00007c88774a2f17 r13 00000000ffffffff r14 0000000000000000 r15 00007ffed3c283d0
F DEBUG : rdi 0000000000000003 rsi 00007ffed3c283bb
F DEBUG : rbp 00007ffed3c28f18 rsp 00007ffed3c28288 rip 00007c890f860761
F DEBUG :
F DEBUG : backtrace:
F DEBUG : #00 pc 0000000000020761 /system/lib64/libc.so (strlen+17)
F DEBUG : #1 pc 000000000006e761 /system/lib64/libc.so (__vfprintf+5953)
F DEBUG : #2 pc 000000000008df5d /system/lib64/libc.so (vsnprintf+189)
F DEBUG : #3 pc 0000000000007b60 /system/lib64/liblog.so (__android_log_vprint+64)
F DEBUG : #4 pc 000000000001350c /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (log_debug_nocheck(_LogCategories, char const*, ...)+204)
F DEBUG : #5 pc 000000000000de6a /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(char const*)+538)
F DEBUG : #6 pc 000000000000df13 /data/app/com.xamarin.DrawableTinting-zvchh4ya_DW11GfpEPFICw==/lib/x86_64/libmonodroid.so (xamarin::android::internal::EmbeddedAssemblies::typemap_java_to_managed(_MonoString*)+99)
F DEBUG : #7 pc 00000000000d57f8 <anonymous:0000000042d04000>
Add the missing parameter to prevent the `SIGSEGV` from happening.
grendello added a commit to grendello/xamarin-android that referenced this pull request May 26, 2020
@grendello
Bump Mono
c28dacf
Fixes: dotnet#4713
Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9
Whenever Xamarin.Android runtime needs to instantiate a managed type, it
first looks it up by calling the following function:
MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);
The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `null`, it should cause Mono to find the correct image
containing the type and load it, if not already loaded.
The pointer is propagated down the call chain inside Mono and due to one
of the functions called not properly validating its arguments, the
`null` pointer was dereferenced, leading to a crash similar to:
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 : dotnet#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 : dotnet#5 pc 0000000000069532 <anonymous:5ad25000>
Mono commit mono/mono@10795da1c06 fixes this issue.
Other changes:
* mono/mono@89d772a3abb Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
* mono/mono@e9d3af508e4 Bump bockbuild to get mono/bockbuild#159
* mono/mono@d6f0c25d34d [2020-02] Bump msbuild to track mono-2019-12 (#19661)
grendello added a commit to grendello/xamarin-android that referenced this pull request May 27, 2020
@grendello
Bump Mono
85ad6c2
Fixes: dotnet#4713
Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9
Whenever Xamarin.Android runtime needs to instantiate a managed type, it
first looks it up by calling the following function:
MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);
The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `null`, it should cause Mono to find the correct image
containing the type and load it, if not already loaded.
The pointer is propagated down the call chain inside Mono and due to one
of the functions called not properly validating its arguments, the
`null` pointer was dereferenced, leading to a crash similar to:
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 : dotnet#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 : dotnet#5 pc 0000000000069532 <anonymous:5ad25000>
Mono commit mono/mono@10795da1c06 fixes this issue.
Other changes:
* mono/mono@89d772a3abb Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
* mono/mono@e9d3af508e4 Bump bockbuild to get mono/bockbuild#159
* mono/mono@d6f0c25d34d [2020-02] Bump msbuild to track mono-2019-12 (#19661)
jonpryor pushed a commit that referenced this pull request May 27, 2020
@grendello
Bump tomono/mono@8c085a99b32(#4725)
9d04571
Fixes: #4713
Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9
Changes: mono/mono@075c3f0...8c085a9
* mono/mono@8c085a99b32: [reflection] Check whether a pointer is valid before dereferencing (#19842)
* mono/mono@89d772a3abb: Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
* mono/mono@e9d3af508e4: Bump bockbuild to get mono/bockbuild#159
* mono/mono@d6f0c25d34d: [2020-02] Bump msbuild to track mono-2019-12 (#19661)
Whenever Xamarin.Android runtime needs to instantiate a managed type,
it first looks it up by calling:
MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);
The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `nullptr`, it should cause Mono to find the correct
image containing the type and load it, if not already loaded.
The pointer is propagated down the call chain inside Mono and due to
one of the functions called not properly validating its arguments, the
`nullptr` pointer was dereferenced, leading to a crash similar to:
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>
Mono commit mono/mono@10795da1c06 fixes this issue.
jonpryor pushed a commit that referenced this pull request May 28, 2020
@grendello@jonpryor
Bump tomono/mono@8c085a99b32(#4725)
af62e27
Fixes: #4713
Context: mono/mono@10795da1c065c
Context: mono/mono@8c085a99b32e9
Changes: mono/mono@075c3f0...8c085a9
* mono/mono@8c085a99b32: [reflection] Check whether a pointer is valid before dereferencing (#19842)
* mono/mono@89d772a3abb: Always include Unicode charinfo, so tar made in csc mode works in mcs mode (#19813)
* mono/mono@e9d3af508e4: Bump bockbuild to get mono/bockbuild#159
* mono/mono@d6f0c25d34d: [2020-02] Bump msbuild to track mono-2019-12 (#19661)
Whenever Xamarin.Android runtime needs to instantiate a managed type,
it first looks it up by calling:
MonoType *type = mono_reflection_type_from_name ("MyType, Assembly", nullptr);
The `nullptr` pointer refers to an instance of the Mono `MonoImage`
structure and if `nullptr`, it should cause Mono to find the correct
image containing the type and load it, if not already loaded.
The pointer is propagated down the call chain inside Mono and due to
one of the functions called not properly validating its arguments, the
`nullptr` pointer was dereferenced, leading to a crash similar to:
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>
Mono commit mono/mono@10795da1c06 fixes this issue.
@hajmajebosshajmajeboss mentioned this pull request Oct 27, 2020
Closed
@LeoJHarrisLeoJHarris mentioned this pull request Jun 1, 2021
Closed
grendello added a commit to grendello/xamarin-android that referenced this pull request Oct 26, 2021
@grendello
Fix heap overflow detected by a clang sanitizer
ce5cf8c
Context: dotnet#6420 (comment)
Clang's AddressSanitizer detected the following:
10-26 15:55:25.393 2488 2488 I Mono.Android_Tests: ==2488==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x8a600774 at pc 0xaeee9982 bp 0xbf98dc68 sp 0xbf98dc60
10-26 15:55:25.394 2488 2488 I Mono.Android_Tests: WRITE of size 4 at 0x8a600774 thread T0
10-26 15:55:25.398 2488 2488 I Mono.Android_Tests: #0 0xaeee9981 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)
10-26 15:55:25.398 2488 2488 I Mono.Android_Tests: #1 0xaeef92d9 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x482d9)
10-26 15:55:25.398 2488 2488 I Mono.Android_Tests: #2 0xaef009ae (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
10-26 15:55:25.398 2488 2488 I Mono.Android_Tests: #3 0xaef06d14 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: 0x8a600774 is located 0 bytes to the right of 4-byte region [0x8a600770,0x8a600774)
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: allocated by thread T0 here:
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: #0 0xaedbe925 (/data/app/Mono.Android_Tests-1/lib/x86/libclang_rt.asan-i686-android.so+0xb6925)
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: #1 0xaeee9ae1 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38ae1)
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: #2 0xaeee9751 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38751)
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: #3 0xaeef92d9 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x482d9)
10-26 15:55:25.399 2488 2488 I Mono.Android_Tests: dotnet#4 0xaef009ae (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
10-26 15:55:25.400 2488 2488 I Mono.Android_Tests: dotnet#5 0xaef06d14 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
10-26 15:55:25.400 2488 2488 I Mono.Android_Tests: dotnet#6 0xb30cb970 (/data/dalvik-cache/x86/data@app@Mono.Android_Tests-1@base.apk@classes.dex+0x5c970)
10-26 15:55:25.400 2488 2488 I Mono.Android_Tests: SUMMARY: AddressSanitizer: heap-buffer-overflow (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)
Address of the offending region points to
`BasicUtilities::monodroid_strsplit` and is likely the line modified in
this commit. Append terminating `nullptr` to vector instead of
overwriting the last element.
jonpryor pushed a commit that referenced this pull request Oct 29, 2021
@grendello
[monodroid] Fix heap overflow detected by a clang sanitizer (#6435)
db7fe5e
Context: #6420 (comment)
Clang's AddressSanitizer detected the following:
Mono.Android_Tests: ==2488==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x8a600774 at pc 0xaeee9982 bp 0xbf98dc68 sp 0xbf98dc60
Mono.Android_Tests: WRITE of size 4 at 0x8a600774 thread T0
Mono.Android_Tests: #0 0xaeee9981 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)
Mono.Android_Tests: #1 0xaeef92d9 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x482d9)
Mono.Android_Tests: #2 0xaef009ae (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
Mono.Android_Tests: #3 0xaef06d14 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
Mono.Android_Tests: 0x8a600774 is located 0 bytes to the right of 4-byte region [0x8a600770,0x8a600774)
Mono.Android_Tests: allocated by thread T0 here:
Mono.Android_Tests: #0 0xaedbe925 (/data/app/Mono.Android_Tests-1/lib/x86/libclang_rt.asan-i686-android.so+0xb6925)
Mono.Android_Tests: #1 0xaeee9ae1 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38ae1)
Mono.Android_Tests: #2 0xaeee9751 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38751)
Mono.Android_Tests: #3 0xaeef92d9 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x482d9)
Mono.Android_Tests: #4 0xaef009ae (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x4f9ae)
Mono.Android_Tests: #5 0xaef06d14 (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x55d14)
Mono.Android_Tests: #6 0xb30cb970 (/data/dalvik-cache/x86/data@app@Mono.Android_Tests-1@base.apk@classes.dex+0x5c970)
Mono.Android_Tests: SUMMARY: AddressSanitizer: heap-buffer-overflow (/data/app/Mono.Android_Tests-1/lib/x86/libmonodroid.so+0x38981)
Address of the offending region points to
`BasicUtilities::monodroid_strsplit()` and is likely the line
modified in this commit. Append terminating `nullptr` to `vector`
instead of overwriting the last element.
jonpryor added a commit that referenced this pull request Jul 21, 2022
@jonpryor
Bump toxamarin/NRefactory@f3242923
7c3ef43
Changes: xamarin/NRefactory@495405a...f324292
* xamarin/NRefactory@f3242923: Add .NET 6.0 target framework
* xamarin/NRefactory@074fabe9: Merge pull request #3 from xamarin/net6
* xamarin/NRefactory@fb5f1535: Merge pull request #4 from xamarin/dev/sandy/obsolete
* xamarin/NRefactory@9233d6a8: Merge pull request #5 from xamarin/dev/sandy/mergemain
* xamarin/NRefactory@b2991f92: Merge remote-tracking branch 'origin/master' into dev/sandy/mergemain
* xamarin/NRefactory@e9c0609e: Fix use of obsolete member
* xamarin/NRefactory@a6885a74: Allow building with .NET 6
@jonpryorjonpryor mentioned this pull request Jul 21, 2022
Closed
grendello added a commit to grendello/xamarin-android that referenced this pull request Sep 15, 2022
@grendello
[WIP] Investigating a Mono.Android crash
ddedcc3
 9-15 22:56:28.431 15070 15090 W monodroid: jclass java_interop_jnienv_find_class(JNIEnv *, jthrowable *, const char *) looking for 'android/content/Intent$ShortcutIconResource'
--------- beginning of crash
09-15 22:56:28.432 15070 15090 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xbb60ca20 in tid 15090 (Instrumentation), pid 15070 (droid.NET_Tests)
09-15 22:56:28.757 15103 15103 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-15 22:56:28.757 15103 15103 F DEBUG : Build fingerprint: 'google/raven/raven:13/TP1A.220624.021/8877034:user/release-keys'
09-15 22:56:28.757 15103 15103 F DEBUG : Revision: 'MP1.0'
09-15 22:56:28.757 15103 15103 F DEBUG : ABI: 'arm64'
09-15 22:56:28.757 15103 15103 F DEBUG : Timestamp: 2022-09-15 22:56:28.545823727+0200
09-15 22:56:28.757 15103 15103 F DEBUG : Process uptime: 3s
09-15 22:56:28.757 15103 15103 F DEBUG : Cmdline: Mono.Android.NET_Tests
09-15 22:56:28.757 15103 15103 F DEBUG : pid: 15070, tid: 15090, name: Instrumentation >>> Mono.Android.NET_Tests <<<
09-15 22:56:28.757 15103 15103 F DEBUG : uid: 10638
09-15 22:56:28.757 15103 15103 F DEBUG : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
09-15 22:56:28.757 15103 15103 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x00000000bb60ca20
09-15 22:56:28.757 15103 15103 F DEBUG : x0 b400006e8ea08350 x1 0000000000000001 x2 0000000000000001 x3 0000000000000010
09-15 22:56:28.757 15103 15103 F DEBUG : x4 0000006dbaea7233 x5 0000006deea682be x6 0000000000000020 x7 0000000000000020
09-15 22:56:28.757 15103 15103 F DEBUG : x8 0000000000000008 x9 00000000bb60c9e0 x10 0000006deea682a7 x11 0000006deea682a7
09-15 22:56:28.757 15103 15103 F DEBUG : x12 3d2120746e696f70 x13 7274706c6c756e20 x14 0000006d3d90b998 x15 000000a74ab3008e
09-15 22:56:28.757 15103 15103 F DEBUG : x16 0000006dbb60f6b8 x17 0000007074e7b9ac x18 0000006d394cc000 x19 0000006d3d90b6d8
09-15 22:56:28.757 15103 15103 F DEBUG : x20 b400006e8ea08350 x21 0000000000000001 x22 0000006d3d90e000 x23 0000006d3d90b6d8
09-15 22:56:28.757 15103 15103 F DEBUG : x24 0000006d3d90b830 x25 0000006d3d90bb80 x26 0000006e7ea14cf0 x27 b400006e8ea08350
09-15 22:56:28.757 15103 15103 F DEBUG : x28 0000000000000000 x29 0000006d3d90b5d0
09-15 22:56:28.757 15103 15103 F DEBUG : lr 0000006dbb16f3dc sp 0000006d3d90b5b0 pc 0000006dbb171d44 pst 0000000080001000
09-15 22:56:28.757 15103 15103 F DEBUG : backtrace:
09-15 22:56:28.757 15103 15103 F DEBUG : #00 pc 0000000000371d44 /apex/com.android.art/lib64/libart.so (art::ArtMethod::PrettyMethod(bool)+76) (BuildId: 56e704c544e6c624201be2ab4933e853)
09-15 22:56:28.757 15103 15103 F DEBUG : #1 pc 000000000036f3d8 /apex/com.android.art/lib64/libart.so (void art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+5464) (BuildId: 56e704c544e6c624201be2ab4933e853)
09-15 22:56:28.757 15103 15103 F DEBUG : #2 pc 00000000005a0370 /apex/com.android.art/lib64/libart.so (art::JNI<true>::FindClass(_JNIEnv*, char const*)+480) (BuildId: 56e704c544e6c624201be2ab4933e853)
09-15 22:56:28.757 15103 15103 F DEBUG : #3 pc 00000000005c8948 /apex/com.android.art/lib64/libart.so (art::(anonymous namespace)::CheckJNI::FindClass(_JNIEnv*, char const*) (.__uniq.99033978352804627313491551960229047428.llvm.5591279935177935698)+228) (BuildId: 56e704c544e6c624201be2ab4933e853)
09-15 22:56:28.757 15103 15103 F DEBUG : dotnet#4 pc 000000000004de28 /data/app/~~aJedheWQLPfk1ulUOfKVyg==/Mono.Android.NET_Tests-XvAL5W7BvZDwkEbYfmLTIQ==/lib/arm64/libmonodroid.so (java_interop_jnienv_find_class+84) (BuildId: a92c56b31adcb233a4674b5eb523c0aaa67a811d)
09-15 22:56:28.757 15103 15103 F DEBUG : dotnet#5 pc 000000000000b220 <anonymous:705fcb1000>
grendello added a commit to grendello/xamarin-android that referenced this pull request Nov 22, 2022
@grendello
[WIP] Add more logging
74f5776
It won't fix the failure, but extra logging might be useful at some
point. The current failure is:
droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of invalid jobject 0x7100941bb830
backtrace:
#00 pc 00000000000943f8 /apex/com.android.runtime/lib64/bionic/libc.so (syscall+24) (BuildId: a08a19770d6696739c847e29c3f5f650)
#1 pc 0000000000097146 /apex/com.android.runtime/lib64/bionic/libc.so (abort+182) (BuildId: a08a19770d6696739c847e29c3f5f650)
#2 pc 000000000055321f /apex/com.android.runtime/lib64/libart.so (art::Runtime::Abort(char const*)+2399) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
#3 pc 000000000000c873 /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+611) (BuildId: 40d2b536dbf0730fdc31abd2b469f94f)
dotnet#4 pc 00000000003ede64 /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1604) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#5 pc 00000000003ee16a /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbortF(char const*, char const*, ...)+234) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#6 pc 00000000005adf7b /apex/com.android.runtime/lib64/libart.so (art::Thread::DecodeJObject(_jobject*) const+875) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#7 pc 00000000003def7b /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckInstance(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck::InstanceKind, _jobject*, bool)+91) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#8 pc 00000000003de1e5 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+485) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#9 pc 00000000003de2d4 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+724) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#10 pc 00000000003dd712 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+690) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#11 pc 00000000003e28c0 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::CheckCallArgs(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck&, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, art::InvokeType, art::(anonymous namespace)::VarArgs const*)+160) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#12 pc 00000000003e1a9e /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::CallMethodV(char const*, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, __va_list_tag*, art::Primitive::Type, art::InvokeType)+910) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#13 pc 00000000003cf551 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::CallObjectMethod(_JNIEnv*, _jobject*, _jmethodID*, ...)+177) (BuildId: 8bb3225e7c408f2ca23abac3db0417f2)
dotnet#14 pc 00000000000013ec /data/app/Mono.Android.NET_Tests--O9vgexkYeCx3nX-AuvLTQ==/split_config.x86_64.apk!libreuse-threads.so (offset 0xa8d000) (BuildId: 562d86d81ebdd3bb6b7528e2a9235ff84827294e)
dotnet#15 pc 0000000000100fce /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+30) (BuildId: a08a19770d6696739c847e29c3f5f650)
dotnet#16 pc 0000000000098fe7 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+55) (BuildId: a08a19770d6696739c847e29c3f5f650)
jonpryor pushed a commit that referenced this pull request Jul 13, 2023
@grendello
[Xamarin.Android.Build.Tasks] per-RID assemblies & typemaps (#8164)
6836818
Context: 929e701
Context: ce2bc68
Context: #7473
Context: #8155
The managed linker can produce assemblies optimized for the target
`$(RuntimeIdentifier)` (RID), which means that they will differ
between different RIDs. Our "favorite" example of this is
`IntPtr.Size`, which is inlined by the linker into `4` or `8` when
targeting 32-bit or 64-bit platforms. (See also #7473 and 929e701.)
Another platform difference may come in the shape of CPU intrinsics
which will change the JIT-generated native code in ways that will
crash the application if the assembler instructions generated for the
intrinsics aren't supported by the underlying processor.
In addition, the per-RID assemblies will have different [MVID][0]s
and **may** have different type and method metadata token IDs, which
is important because typemaps *use* type and metadata token IDs; see
also ce2bc68.
All of this taken together invalidates our previous assumption that
all the managed assemblies are identical. "Simply" using
`IntPtr.Size` in an assembly that contains `Java.Lang.Object`
subclasses will break things.
This in turn could cause "mysterious" behavior or crashes in Release
applications; see also Issue #8155.
Prevent the potential problems by processing each per-RID assembly
separately and output correct per-RID LLVM IR assembly using the
appropriate per-RID information.
Additionally, during testing I found that for our use of Cecil within
`<GenerateJavaStubs/>` doesn't consistently remove the fields,
delegates, and methods we remove in `MarshalMethodsAssemblyRewriter`
when marshal methods are enabled, or it generates subtly broken
assemblies which cause **some** applications to segfault at run time
like so:
I monodroid-gc: 1 outstanding GREFs. Performing a full GC!
F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8 in tid 12379 (t6.helloandroid), pid 12379 (t6.helloandroid)
F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
F DEBUG : Build fingerprint: 'google/raven_beta/raven:14/UPB3.230519.014/10284690:user/release-keys'
F DEBUG : Revision: 'MP1.0'
F DEBUG : ABI: 'arm64'
F DEBUG : Timestamp: 2023-07-04 22:09:58.762982002+0200
F DEBUG : Process uptime: 1s
F DEBUG : Cmdline: com.microsoft.net6.helloandroid
F DEBUG : pid: 12379, tid: 12379, name: t6.helloandroid >>> com.microsoft.net6.helloandroid <<<
F DEBUG : uid: 10288
F DEBUG : tagged_addr_ctrl: 0000000000000001 (PR_TAGGED_ADDR_ENABLE)
F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0000000000000008
F DEBUG : Cause: null pointer dereference
F DEBUG : x0 0000000000000000 x1 0000007ba1401af0 x2 00000000000000fa x3 0000000000000001
F DEBUG : x4 0000007ba1401b38 x5 0000007b9f2a8360 x6 0000000000000000 x7 0000000000000000
F DEBUG : x8 ffffffffffc00000 x9 0000007b9f800000 x10 0000000000000000 x11 0000007ba1400000
F DEBUG : x12 0000000000000000 x13 0000007ba374ad58 x14 0000000000000000 x15 00000013ead77d66
F DEBUG : x16 0000007ba372f210 x17 0000007ebdaa4a80 x18 0000007edf612000 x19 000000000000001f
F DEBUG : x20 0000000000000000 x21 0000007b9f2a8320 x22 0000007b9fb02000 x23 0000000000000018
F DEBUG : x24 0000007ba374ad08 x25 0000000000000004 x26 0000007b9f2a4618 x27 0000000000000000
F DEBUG : x28 ffffffffffffffff x29 0000007fc592a780
F DEBUG : lr 0000007ba3701f44 sp 0000007fc592a730 pc 0000007ba3701e0c pst 0000000080001000
F DEBUG : 8 total frames
F DEBUG : backtrace:
F DEBUG : #00 pc 00000000002d4e0c /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #1 pc 00000000002c29e8 /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #2 pc 00000000002c34bc /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #3 pc 00000000002c2254 /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #4 pc 00000000002be0bc /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #5 pc 00000000002bf050 /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #6 pc 00000000002a53a4 /data/app/~~Av24J15xbf20XdrY3X2_wA==/com.microsoft.net6.helloandroid-4DusuNWIAkz1Ssi7fWVF-g==/lib/arm64/libmonosgen-2.0.so (mono_gc_collect+44) (BuildId: 761134f2369377582cc3a8e25ecccb43a2e0a877)
F DEBUG : #7 pc 000000000000513c <anonymous:7ec716b000>
This is because we generate Java Callable Wrappers over a set of
original (linked or not) assemblies, then we scan them for classes
derived from `Java.Lang.Object` and use that set as input to the
marshal methods rewriter, which makes the changes (generates wrapper
methods, decorates wrapped methods with `[UnmanagedCallersOnly]`,
removes the old delegate methods as well as delegate backing fields)
to all the `Java.Lang.Object` subclasses, then writes the modified
assembly to a `new/<assembly.dll>` location (efa14e2), followed by
copying the newly written assemblies back to the original location.
At this point, we have the results returned by the subclass scanner
in memory and **new** versions of those types on disk, but they are
out of sync, since the types in memory refer to the **old** assemblies,
but AOT is ran on the **new** assemblies which have a different layout,
changed MVIDs and, potentially, different type and method token IDs
(because we added some methods, removed others etc) and thus it causes
the crashes at the run time. The now invalid set of "old" types is
passed to the typemap generator. This only worked by accident, because
we (incorrectly) used only the first linked assembly which happened
to be the same one passed to the JLO scanner and AOT - so everything
was fine at the execution time.
Address this by *disabling* LLVM Marshal Methods (8bc7a3e) for .NET 8,
setting `$(AndroidEnableMarshalMethods)`=False by default.
We'll attempt to fix these issues for .NET 9.
[0]: https://learn.microsoft.com/dotnet/api/system.reflection.module.moduleversionid?view=net-7.0
jonpryor added a commit that referenced this pull request Jan 26, 2024
@jonpryor
Audit JNIEnv::GetObjectClass() invocations
b4ca587
Context: dotnet/java-interop@6b3637d
The story so far is that some of our unit tests are crashing, and
have been in one form or another since 4332ea0
(the bump to dotnet/java-interop@def5bc0).
The current crash, from the PR build for 7b46391:
D monodroid-assembly: typemap: assembly 'Java.Interop-Tests' hasn't been loaded yet, attempting a full load
W monodroid-assembly: typemap: failed to load managed assembly 'Java.Interop-Tests.dll'. No such file or directory
E monodroid-assembly: typemap: unable to load assembly 'Java.Interop-Tests' when looking up managed type corresponding to Java type 'java/lang/Object'
I monodroid-timing: [1/5] Typemap.java_to_managed: end, total time; elapsed: 0:0::260000
W monodroid-assembly: typemap: called from
W monodroid-assembly: at Java.Interop.TypeManager.GetJavaToManagedType(String )
W monodroid-assembly: at Java.Interop.TypeManager.CreateInstance(IntPtr , JniHandleOwnership , Type )
W monodroid-assembly: at Java.Lang.Object.GetObject(IntPtr , JniHandleOwnership , Type )
W monodroid-assembly: at Java.Lang.Object._GetObject[IIterator](IntPtr , JniHandleOwnership )
W monodroid-assembly: at Java.Lang.Object.GetObject[IIterator](IntPtr handle, JniHandleOwnership transfer)
W monodroid-assembly: at Android.Runtime.JavaSet.Iterator()
W monodroid-assembly: at Android.Runtime.JavaSet`1[[System.String, System.Private.CoreLib, Version=9.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].GetEnumerator()
W monodroid-assembly: at Xamarin.Android.UnitTests.TestInstrumentation`1[[Xamarin.Android.UnitTests.NUnit.NUnitTestRunner, TestRunner.NUnit.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].ProcessArguments()
W monodroid-assembly: at Xamarin.Android.UnitTests.TestInstrumentation`1[[Xamarin.Android.UnitTests.NUnit.NUnitTestRunner, TestRunner.NUnit.NET, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]].OnCreate(Bundle arguments)
W monodroid-assembly: at Android.App.Instrumentation.n_OnCreate_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_arguments)
W monodroid-assembly: at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PPL_V(_JniMarshal_PPL_V callback, IntPtr jnienv, IntPtr klazz, IntPtr p0)
E droid.NET_Test: JNI ERROR (app bug): accessed stale Local 0x75 (index 7 in a table of size 7)
F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75
There are *three* "concerning" items here:
1. typemaps are trying to load `Java.Interop-Tests`, and failing:
typemap: failed to load managed assembly 'Java.Interop-Tests.dll'. No such file or directory
@grendello is looking into this.
2. The binding for `java/lang/Object` is coming from
Java.Interop-Tests, not Mono.Android (?!)
typemap: unable to load assembly 'Java.Interop-Tests' when looking up managed type corresponding to Java type 'java/lang/Object'
dotnet/java-interop#1181 has a fix for this, and we're not
applying the fix yet because we believe that it will hide (1).
3. The JNI error, which crashes the process:
F droid.NET_Test: java_vm_ext.cc:570] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75
F droid.NET_Test: java_vm_ext.cc:570] from void crc643df67da7b13bb6b1.TestInstrumentation_1.n_onCreate(android.os.Bundle)
F droid.NET_Test: runtime.cc:630] Runtime aborting...
F droid.NET_Test: runtime.cc:630] Dumping all threads without mutator lock held
F droid.NET_Test: runtime.cc:630] All threads:
F droid.NET_Test: runtime.cc:630] DALVIK THREADS (14):
F droid.NET_Test: runtime.cc:630] "main" prio=5 tid=1 Runnable
F droid.NET_Test: runtime.cc:630] | group="" sCount=0 dsCount=0 flags=0 obj=0x729e9d98 self=0x7567e0f51000
F droid.NET_Test: runtime.cc:630] | sysTid=9143 nice=0 cgrp=default sched=0/0 handle=0x7567e14daed8
F droid.NET_Test: runtime.cc:630] | state=R schedstat=( 1270418000 334229000 139 ) utm=16 stm=110 core=0 HZ=100
F droid.NET_Test: runtime.cc:630] | stack=0x7ffcbb3e4000-0x7ffcbb3e6000 stackSize=8192KB
F droid.NET_Test: runtime.cc:630] | held mutexes= "abort lock" "mutator lock"(shared held)
F droid.NET_Test: runtime.cc:630] native: #00 pc 000000000048df4e /apex/com.android.runtime/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+126)
F droid.NET_Test: runtime.cc:630] native: #1 pc 00000000005a77c3 /apex/com.android.runtime/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool, BacktraceMap*, bool) const+675)
F droid.NET_Test: runtime.cc:630] native: #2 pc 00000000005c49cb /apex/com.android.runtime/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+859)
F droid.NET_Test: runtime.cc:630] native: #3 pc 00000000005bcf28 /apex/com.android.runtime/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+456)
F droid.NET_Test: runtime.cc:630] native: #4 pc 00000000005bc2e1 /apex/com.android.runtime/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char>>&, bool)+1601)
F droid.NET_Test: runtime.cc:630] native: #5 pc 0000000000552eb9 /apex/com.android.runtime/lib64/libart.so (art::Runtime::Abort(char const*)+1529)
F droid.NET_Test: runtime.cc:630] native: #6 pc 000000000000c873 /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+611)
F droid.NET_Test: runtime.cc:630] native: #7 pc 00000000003ede84 /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1604)
F droid.NET_Test: runtime.cc:630] native: #8 pc 00000000003ee18a /apex/com.android.runtime/lib64/libart.so (art::JavaVMExt::JniAbortF(char const*, char const*, ...)+234)
F droid.NET_Test: runtime.cc:630] native: #9 pc 00000000005adf31 /apex/com.android.runtime/lib64/libart.so (art::Thread::DecodeJObject(_jobject*) const+785)
F droid.NET_Test: runtime.cc:630] native: #10 pc 00000000003def9b /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckInstance(art::ScopedObjectAccess&, art::(anonymous namespace)::ScopedCheck::InstanceKind, _jobject*, bool)+91)
F droid.NET_Test: runtime.cc:630] native: #11 pc 00000000003de205 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::CheckPossibleHeapValue(art::ScopedObjectAccess&, char, art::(anonymous namespace)::JniValueType)+485)
F droid.NET_Test: runtime.cc:630] native: #12 pc 00000000003dd732 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::ScopedCheck::Check(art::ScopedObjectAccess&, bool, char const*, art::(anonymous namespace)::JniValueType*)+690)
F droid.NET_Test: runtime.cc:630] native: #13 pc 00000000003ce865 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::GetObjectClass(_JNIEnv*, _jobject*)+837)
F droid.NET_Test: runtime.cc:630] native: #14 pc 0000000000017196 /data/app/Mono.Android.NET_Tests-LUUW792fOvX745oAS4jeRQ==/split_config.x86_64.apk (offset 331000) (???)
F droid.NET_Test: runtime.cc:630] at crc643df67da7b13bb6b1.TestInstrumentation_1.n_onCreate(Native method)
As per `native #13`, we're (somehow) passing an invalid JNI reference
to `JNIEnv::GetObjectClass()`.
***HOW*** are we passing an invalid JNI reference to
`JNIEnv::GetObjectClass()`?
Attempt to investigate (3) further, by:
1. Reviewing all calls to `JNIEnv::GetObjectClass()` within this
repo to see if we could potentially be passing an invalid value.
The "most obvious" candidate is `TypeManager.CreateInstance()`,
which calls `JNIEnv::GetObjectClass()` in a loop.
I'm still not sure if that could possibly be the cause, but
Just In Case™…
"Cleanup" some C++ code so that calls to
`JNIEnv::DeleteLocalReference()` are closer to the
`JNIEnv::GetObjectClass()` calls.
2. Update
`tests/Mono.Android-Tests/Runtime-Microsoft.Android.Sdk/Mono.Android.NET-Tests.csproj`
to add an `@(AndroidEnvironment)` item, which sets
`debug.mono.log=gref+,lref+`. This will enable LREF and GREF
logging within `adb logcat`, which *may* allow us to track down
where "local reference 0x75" came from.
@github-actionsgithub-actionsBot locked and limited conversation to collaborators Feb 2, 2024
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

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.

2 participants

@dellis1972@jonpryor