Remove Mono.Android-Tests.csproj from Xamarin.Android.sln. #65
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When Mono.Android-Tests was added at 1b3a76c no one verified that Xamarin.Android.sln builds from the clean state. It actually depends on *existing* Xamarin.Android SDK so it never built when building the SDK itself. Removing this from the solution so far.
|
PR#79 should have superceded this PR. |
radical
pushed a commit
that referenced
this pull request
May 8, 2018
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.
grendello
pushed a commit
that referenced
this pull request
Aug 12, 2020
Fixes: dotnet/android-libzipsharp#64 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1139578 Context: https://liquid.microsoft.com/Web/Object/Read/ms.security/Requirements/Microsoft.Security.SystemsADM.10039#guide Changes: dotnet/android-libzipsharp@1.0.10...1.0.20 * dotnet/android-libzipsharp@1752f95: Statically Linux libzip.so (#70) * dotnet/android-libzipsharp@2b1762f: Fix Dll SearchPath to include Assembly Directory. (#69) * dotnet/android-libzipsharp@28b4639: Merge pull request #68 from dellis1972/fixwindowssearch * dotnet/android-libzipsharp@fdabcda: Fix Windows to look in Assembly Directory for 32bit dll. * dotnet/android-libzipsharp@b332af0: Fix Native Crash on Windows. (#67) * dotnet/android-libzipsharp@96eb5e3: Use DefaultDllImportSearchPathsAttribute (#66) * dotnet/android-libzipsharp@755a42a: Bump libzip to 1.7.3 and go back to mingw (#65) * dotnet/android-libzipsharp@5ae5e70: Merge pull request #60 from xamarin/msvc-static-link * dotnet/android-libzipsharp@30ff680: Build libzip with static CRT and VS2019 * dotnet/android-libzipsharp@bad320e: Merge pull request #59 from dellis1972/theswitcharoo * dotnet/android-libzipsharp@d7bc2c5: Merge pull request #58 from xamarin/optimize-winbuild * dotnet/android-libzipsharp@34dc213: Make 64 bit Linux native lib the default. * dotnet/android-libzipsharp@d3aad35: fixup! Optimize libzip build * dotnet/android-libzipsharp@0970a01: Optimize libzip build * dotnet/android-libzipsharp@d321af1: Merge pull request #57 from xamarin/fix-win32-packaging * dotnet/android-libzipsharp@80b739d: Fix a typo which caused 64-bit dll to be packaged for 32-bit Windows * dotnet/android-libzipsharp@1665db0: Bump the version (to 1.0.12), to prepare to release (#56) * dotnet/android-libzipsharp@dd5e939: Throw exception instead of silently failing if zip save/close fails (#54) * dotnet/android-libzipsharp@2df5b16: Fix enumerating zip with deleted entries (#53) * dotnet/android-libzipsharp@a042554: Add .editorconfig, copied from xamarin-android (#55) * dotnet/android-libzipsharp@a0973d4: Bump libzip to 1.6.1 (#49) Changes: nih-at/libzip@rel-1-5-1...v1.7.3 * Context: https://libzip.org/news/release-1.7.3.html * Context: https://libzip.org/news/release-1.7.2.html * Context: https://libzip.org/news/release-1.7.1.html * Context: https://libzip.org/news/release-1.7.0.html Two primary changes of note in this xamarin/LibZipSharp bump: 1. Bump to `libzip` 1.7.3, which contains numerious fixes and improvements over the previously used 1.5.1 release. 2. Use of `DefaultDllImportSearchPathsAttribute` so that native library dependencies are loaded securely, i.e. w/o allowing "other" libraries to be loaded from unsafe directories. Unfortunately, the `libzip` bump itself caused issues, PR #4751 and PR #4937 each had integration tests "randomly" SIGSEGV. This was eventually tracked down to a bug within `libzip` itself, fixed at: * nih-at/libzip#202
jonpryor
pushed a commit
that referenced
this pull request
Aug 20, 2020
Fixes: dotnet/android-libzipsharp#64 Context: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1139578 Context: https://liquid.microsoft.com/Web/Object/Read/ms.security/Requirements/Microsoft.Security.SystemsADM.10039#guide Changes: dotnet/android-libzipsharp@1.0.10...1.0.20 * dotnet/android-libzipsharp@1752f95: Statically Linux libzip.so (#70) * dotnet/android-libzipsharp@2b1762f: Fix Dll SearchPath to include Assembly Directory. (#69) * dotnet/android-libzipsharp@28b4639: Merge pull request #68 from dellis1972/fixwindowssearch * dotnet/android-libzipsharp@fdabcda: Fix Windows to look in Assembly Directory for 32bit dll. * dotnet/android-libzipsharp@b332af0: Fix Native Crash on Windows. (#67) * dotnet/android-libzipsharp@96eb5e3: Use DefaultDllImportSearchPathsAttribute (#66) * dotnet/android-libzipsharp@755a42a: Bump libzip to 1.7.3 and go back to mingw (#65) * dotnet/android-libzipsharp@5ae5e70: Merge pull request #60 from xamarin/msvc-static-link * dotnet/android-libzipsharp@30ff680: Build libzip with static CRT and VS2019 * dotnet/android-libzipsharp@bad320e: Merge pull request #59 from dellis1972/theswitcharoo * dotnet/android-libzipsharp@d7bc2c5: Merge pull request #58 from xamarin/optimize-winbuild * dotnet/android-libzipsharp@34dc213: Make 64 bit Linux native lib the default. * dotnet/android-libzipsharp@d3aad35: fixup! Optimize libzip build * dotnet/android-libzipsharp@0970a01: Optimize libzip build * dotnet/android-libzipsharp@d321af1: Merge pull request #57 from xamarin/fix-win32-packaging * dotnet/android-libzipsharp@80b739d: Fix a typo which caused 64-bit dll to be packaged for 32-bit Windows * dotnet/android-libzipsharp@1665db0: Bump the version (to 1.0.12), to prepare to release (#56) * dotnet/android-libzipsharp@dd5e939: Throw exception instead of silently failing if zip save/close fails (#54) * dotnet/android-libzipsharp@2df5b16: Fix enumerating zip with deleted entries (#53) * dotnet/android-libzipsharp@a042554: Add .editorconfig, copied from xamarin-android (#55) * dotnet/android-libzipsharp@a0973d4: Bump libzip to 1.6.1 (#49) Changes: nih-at/libzip@rel-1-5-1...v1.7.3 * Context: https://libzip.org/news/release-1.7.3.html * Context: https://libzip.org/news/release-1.7.2.html * Context: https://libzip.org/news/release-1.7.1.html * Context: https://libzip.org/news/release-1.7.0.html Two primary changes of note in this xamarin/LibZipSharp bump: 1. Bump to `libzip` 1.7.3, which contains numerious fixes and improvements over the previously used 1.5.1 release. 2. Use of `DefaultDllImportSearchPathsAttribute` so that native library dependencies are loaded securely, i.e. w/o allowing "other" libraries to be loaded from unsafe directories. Unfortunately, the `libzip` bump itself caused issues, PR #4751 and PR #4937 each had integration tests "randomly" SIGSEGV. This was eventually tracked down to a bug within `libzip` itself, fixed at: * nih-at/libzip#202
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When Mono.Android-Tests was added at 1b3a76c no one verified that
Xamarin.Android.sln builds from the clean state. It actually depends
on existing Xamarin.Android SDK so it never built when building
the SDK itself.
Removing this from the solution so far.