Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Remove Mono.Android-Tests.csproj from Xamarin.Android.sln. #65

Closed

Conversation

atsushieno
Copy link
Contributor

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.

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.
@atsushieno
Copy link
Contributor Author

PR#79 should have superceded this PR.

@atsushieno atsushieno closed this Jun 15, 2016
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
@github-actions github-actions bot locked and limited conversation to collaborators Feb 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants