Bump manifest-merger from 30.2.0 to 30.2.1 in /src/manifestmerger #2
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
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps manifest-merger from 30.2.0 to 30.2.1. --- updated-dependencies: - dependency-name: com.android.tools.build:manifest-merger dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
the
dependencies
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
bot
deleted the
dependabot/gradle/src/manifestmerger/com.android.tools.build-manifest-merger-30.2.1
branch
simonrozsival
pushed a commit
that referenced
this pull request
May 31, 2022
Context: dotnet/install-scripts#15 Context: https://dot.net/v1/dotnet-install.sh Context: https://dot.net/v1/dotnet-install.ps1 We've been installing dotnet versions using the [`dotnet-install`][0] scripts for Unix & Windows. However, they do not cache the downloaded archive, and therefore we end up re-downloading the same archive over and over again. Additionally, if one finds themselves without an internet connection, there's no way to easily install the required version of dotnet. The installation scripts don't provide a way to cache the payloads and they appear to be in maintenance mode (dotnet/install-scripts#15), so there doesn't appear to be a chance to add caching support to them. Fortunately, we can "ask" the scripts what they're downloading: % curl -o dotnet-install.sh 'https://dot.net/v1/dotnet-install.sh' % ./dotnet-install.sh --version 7.0.100-preview.5.22273.1 --verbose --dry-run \ | grep 'dotnet-install: URL' This returns a list of URLs, which may or may not exist: dotnet-install: URL #0 - primary: https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.100-preview.5.22273.1/dotnet-sdk-7.0.100-preview.5.22273.1-osx-x64.tar.gz dotnet-install: URL #1 - legacy: https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.100-preview.5.22273.1/dotnet-dev-osx-x64.7.0.100-preview.5.22273.1.tar.gz dotnet-install: URL #2 - primary: https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-preview.5.22273.1/dotnet-sdk-7.0.100-preview.5.22273.1-osx-x64.tar.gz dotnet-install: URL #3 - legacy: https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-preview.5.22273.1/dotnet-dev-osx-x64.7.0.100-preview.5.22273.1.tar.gz We now parse this output, extract the URLs, then download and cache the URL contents into `$(AndroidToolchainCacheDirectory)`. When we need to install .NET, we just extract the cached archive into the appropriate directory. If no `dotnet-install: URL…` messages are generated, then we run the `dotnet-install` script as we previously did. This process lets us take a first step towards fully "offline" builds, along with smaller downloads on CI servers. [0]: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
simonrozsival
pushed a commit
that referenced
this pull request
May 31, 2022
Context: dotnet/install-scripts#15 Context: https://dot.net/v1/dotnet-install.sh Context: https://dot.net/v1/dotnet-install.ps1 We've been installing dotnet versions using the [`dotnet-install`][0] scripts for Unix & Windows. However, they do not cache the downloaded archive, and therefore we end up re-downloading the same archive over and over again. Additionally, if one finds themselves without an internet connection, there's no way to easily install the required version of dotnet. The installation scripts don't provide a way to cache the payloads and they appear to be in maintenance mode (dotnet/install-scripts#15), so there doesn't appear to be a chance to add caching support to them. Fortunately, we can "ask" the scripts what they're downloading: % curl -o dotnet-install.sh 'https://dot.net/v1/dotnet-install.sh' % ./dotnet-install.sh --version 7.0.100-preview.5.22273.1 --verbose --dry-run \ | grep 'dotnet-install: URL' This returns a list of URLs, which may or may not exist: dotnet-install: URL #0 - primary: https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.100-preview.5.22273.1/dotnet-sdk-7.0.100-preview.5.22273.1-osx-x64.tar.gz dotnet-install: URL #1 - legacy: https://dotnetcli.azureedge.net/dotnet/Sdk/7.0.100-preview.5.22273.1/dotnet-dev-osx-x64.7.0.100-preview.5.22273.1.tar.gz dotnet-install: URL #2 - primary: https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-preview.5.22273.1/dotnet-sdk-7.0.100-preview.5.22273.1-osx-x64.tar.gz dotnet-install: URL #3 - legacy: https://dotnetbuilds.azureedge.net/public/Sdk/7.0.100-preview.5.22273.1/dotnet-dev-osx-x64.7.0.100-preview.5.22273.1.tar.gz We now parse this output, extract the URLs, then download and cache the URL contents into `$(AndroidToolchainCacheDirectory)`. When we need to install .NET, we just extract the cached archive into the appropriate directory. If no `dotnet-install: URL…` messages are generated, then we run the `dotnet-install` script as we previously did. This process lets us take a first step towards fully "offline" builds, along with smaller downloads on CI servers. [0]: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
simonrozsival
pushed a commit
that referenced
this pull request
Dec 11, 2023
…otnet#7732) Fixes: dotnet#7335 Context: d236af5 Commit d236af5 introduced embedded assembly compression, using LZ4, which speeds up startup and reduces final package size. Assemblies are compressed at build time and, at the same time, pre- allocated buffers for the **decompressed** data are allocated in `libxamarin-app.so`. The buffers are then passed to the LZ4 APIs, all threads using the same output buffer. The assumption was that we can do fine without locking as even if overlapped decompression happens, the output data will be the same and so even if two threads do the same thing at the same time, the data will be valid at all times, so long as at least one thread completes the decompression. This assumption proved to be **largely** true, but it appears that in high concurrency cases it is possible that the data in the decompression buffer differs. This can result in app crashes: A/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3092 (.NET ThreadPool), pid 2727 (myapp.name) A/DEBUG: pid: 2727, tid: 3092, name: .NET ThreadPool >>> myapp.name <<< A/DEBUG: #1 pc 0000000000029b1c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmono-android.release.so (offset 0x103d000) (xamarin::android::internal::MonodroidRuntime::mono_log_handler(char const*, char const*, char const*, int, void*)+144) (BuildId: 29c5a3805a0bedee1eede9b6668d7c676aa63371) A/DEBUG: #2 pc 00000000002680bc /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: #3 pc 00000000002681e8 /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) A/DEBUG: #4 pc 000000000008555c /data/app/myapp.name-B9t_3dF9i8mDxJEKodZw5w==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (offset 0x109b000) (mono_metadata_string_heap+188) (BuildId: 4a5dd4396e8816b7f69881838bd549285213d53b) … My guess is that LZ4 either uses the output buffer as a scratchpad area when decompressing or that it initializes/modifies the buffer before writing actual data in it. With overlapped decompression, it may lead to one thread overwriting valid data previously written by another thread, so that when the latter returns the buffer it thought to have had valid data may contain certain bytes temporarily overwritten by the decompression session in the other, still running, thread. It may happen that MonoVM reads the corrupted data just when it is still invalid (before the still running decompression session actually writes the valid data), a classic race condition. To fix this, the decompression block is now protected with a startup- aware mutex. Mutex will be held only after the initial startup phase is completed, so there should not be much loss of startup performance.
simonrozsival
added a commit
that referenced
this pull request
Dec 11, 2023
Changes: dotnet/installer@9962c6a...779a644 Changes: dotnet/linker@4b3f78c...c790896 Changes: dotnet/runtime@5da4a9e...ddb6988 Changes: dotnet/emsdk@66b9845...5b46122 Updates: * Microsoft.Dotnet.Sdk.Internal: from 8.0.100-alpha.1.23063.11 to 8.0.100-alpha.1.23070.23 * Microsoft.NET.ILLink.Tasks: from 8.0.100-1.23055.2 to 8.0.100-1.23067.1 * Microsoft.NETCore.App.Ref: from 8.0.0-alpha.1.23058.2 to 8.0.0-alpha.1.23070.1 * Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100: from 8.0.0-alpha.1.22620.1 to 8.0.0-alpha.1.23066.1 ~~ Other Changes ~~ * Update `.apkdesc` files for app size changes. * Use .jar files from the .NET runtime pack (dotnet#7665) Since [dotnet/runtime#77386][0] has been merged, .NET will require a certain class from `libSystem.Security.Cryptography.Native.Android.jar` that will be located in the runtime pack files. [0]: dotnet/runtime#77386 * Disambiguate `.jar` files from Mono runtime packs. We were getting the build error: error JAVA0000: Caused by: com.android.tools.r8.internal.f: Type net.dot.android.crypto.DotnetProxyTrustManager is defined multiple times This `.jar` file is contained in each runtime pack (4 architectures) gives us 4 `.jar` files! We can pass in these files to the `<ProcessAssemblies/>` MSBuild task. We also filter them based on `%(NuGetPackageId)`, so that any random `.jar` file doesn't get added to `@(AndroidJavaLibrary)`. I renamed the `IsFrameworkAssembly()` method to `IsFromAKnownRuntimePack()` to make this more clear in the existing code. * Update `proguard_xamarin.cfg` for .NET 8. Apps using `$(AndroidLinkTool)` of r8, now need to preserve: -keep class net.dot.android.crypto.DotnetProxyTrustManager { *; <init>(...); } Otherwise we run into a crash when this type isn't present, such as: 01-26 23:59:19.855 8684 8684 F DEBUG : #2 pc 00000000000191d6 /data/app/Mono.Android.NET_Tests-cpTzt8Q9KwgS-znzkuAdNQ==/split_config.x86_64.apk!libSystem.Security.Cryptography.Native.Android.so (offset 0xe7000) (JNI_OnLoad+31302) (BuildId: 7d9e4013a9dd99810070587ab42956703fef69f9) Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com> Co-authored-by: Šimon Rozsíval <simon@rozsival.com>
simonrozsival
pushed a commit
that referenced
this pull request
Dec 11, 2023
) Context: 929e701 Context: ce2bc68 Context: dotnet#7473 Context: dotnet#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 dotnet#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 dotnet#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
pushed a commit
that referenced
this pull request
Jul 25, 2024
Context: dotnet/maui#23694 (review) Context: https://github.com/dotnet/maui/blob/d38ca872f68326ab623c050b0efd93c7d212e000/src/Essentials/test/DeviceTests/Tests/Preferences_Tests.cs#L305-L310 Context: dotnet/android@06bb1dc...45855b8 A .NET MAUI on-device test is crashing on API 23 emulators: 07-23 11:35:45.837 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512) 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] local reference table dump: 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] Last 10 entries (of 512): 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 511: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 510: 0x6ff7db18 java.lang.Class<android.app.SharedPreferencesImpl$EditorImpl> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 509: 0x6fed5750 java.lang.Class<android.content.SharedPreferences$Editor> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 508: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 507: 0x6fed57d8 java.lang.Class<android.content.SharedPreferences> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 506: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 505: 0x6fed57d8 java.lang.Class<android.content.SharedPreferences> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 504: 0x6ff7db18 java.lang.Class<android.app.SharedPreferencesImpl$EditorImpl> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 503: 0x6fed5750 java.lang.Class<android.content.SharedPreferences$Editor> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 502: 0x6ff7e140 java.lang.Class<android.app.SharedPreferencesImpl> 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] Summary: 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 511 of java.lang.Class (7 unique instances) 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 1 of android.app.SharedPreferencesImpl 07-23 11:35:45.839 4252 4277 F art : art/runtime/indirect_reference_table.cc:115] 07-23 11:35:45.930 4252 4277 F art : art/runtime/barrier.cc:90] Check failed: count_ == 0 (count_=-1, 0=0) Attempted to destroy barrier with non zero count 07-23 11:35:45.930 4252 4277 F art : art/runtime/runtime.cc:366] Runtime aborting --- recursively, so no thread-specific detail! 07-23 11:35:45.930 4252 4277 F art : art/runtime/runtime.cc:366] --------- beginning of crash 07-23 11:35:45.930 4252 4277 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 4277 (.NET TP Worker) 07-23 11:35:46.003 1640 1640 I SELinux : SELinux: Loaded file_contexts contexts from /file_contexts. 07-23 11:35:46.006 1640 1640 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 07-23 11:35:46.006 1640 1640 F DEBUG : Build fingerprint: 'Android/sdk_google_phone_x86_64/generic_x86_64:6.0/MASTER/6695544:userdebug/test-keys' 07-23 11:35:46.006 1640 1640 F DEBUG : Revision: '0' 07-23 11:35:46.006 1640 1640 F DEBUG : ABI: 'x86_64' 07-23 11:35:46.006 1640 1640 F DEBUG : pid: 4252, tid: 4277, name: .NET TP Worker >>> com.microsoft.maui.essentials.devicetests <<< 07-23 11:35:46.006 1640 1640 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 07-23 11:35:46.014 1640 1640 F DEBUG : Abort message: 'art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512)' 07-23 11:35:46.014 1640 1640 F DEBUG : rax 0000000000000000 rbx 00007f7dadfbf500 rcx ffffffffffffffff rdx 0000000000000006 07-23 11:35:46.014 1640 1640 F DEBUG : rsi 00000000000010b5 rdi 000000000000109c 07-23 11:35:46.014 1640 1640 F DEBUG : r8 0000000000000001 r9 0000000000000003 r10 0000000000000008 r11 0000000000000206 07-23 11:35:46.014 1640 1640 F DEBUG : r12 00000000000010b5 r13 0000000000000006 r14 00007f7dc7305a40 r15 00007f7dabd70cc0 07-23 11:35:46.014 1640 1640 F DEBUG : cs 0000000000000033 ss 000000000000002b 07-23 11:35:46.014 1640 1640 F DEBUG : rip 00007f7dcaa49a67 rbp 0000000000000002 rsp 00007f7dadfbc048 eflags 0000000000000206 07-23 11:35:46.018 1640 1640 F DEBUG : 07-23 11:35:46.018 1640 1640 F DEBUG : backtrace: 07-23 11:35:46.019 1640 1640 F DEBUG : #00 pc 0000000000087a67 /system/lib64/libc.so (tgkill+7) 07-23 11:35:46.019 1640 1640 F DEBUG : #1 pc 0000000000085b11 /system/lib64/libc.so (pthread_kill+65) 07-23 11:35:46.019 1640 1640 F DEBUG : #2 pc 000000000002e841 /system/lib64/libc.so (raise+17) 07-23 11:35:46.019 1640 1640 F DEBUG : #3 pc 00000000000288fd /system/lib64/libc.so (abort+61) 07-23 11:35:46.019 1640 1640 F DEBUG : #4 pc 00000000004ffd65 /system/lib64/libart.so (art::Runtime::Abort()+341) 07-23 11:35:46.019 1640 1640 F DEBUG : #5 pc 0000000000178d71 /system/lib64/libart.so (art::LogMessage::~LogMessage()+2865) 07-23 11:35:46.019 1640 1640 F DEBUG : #6 pc 0000000000172dad /system/lib64/libart.so (art::Barrier::~Barrier()+813) 07-23 11:35:46.019 1640 1640 F DEBUG : #7 pc 000000000053de1a /system/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+394) 07-23 11:35:46.019 1640 1640 F DEBUG : #8 pc 00000000004ffea4 /system/lib64/libart.so (art::Runtime::Abort()+660) 07-23 11:35:46.019 1640 1640 F DEBUG : #9 pc 0000000000178d71 /system/lib64/libart.so (art::LogMessage::~LogMessage()+2865) 07-23 11:35:46.019 1640 1640 F DEBUG : #10 pc 00000000002f00fd /system/lib64/libart.so (art::IndirectReferenceTable::Add(unsigned int, art::mirror::Object*)+1005) 07-23 11:35:46.019 1640 1640 F DEBUG : #11 pc 00000000003ee19a /system/lib64/libart.so (art::JNI::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, __va_list_tag*)+586) 07-23 11:35:46.019 1640 1640 F DEBUG : #12 pc 00000000001abdf8 /system/lib64/libart.so (art::CheckJNI::CallMethodV(char const*, _JNIEnv*, _jobject*, _jclass*, _jmethodID*, __va_list_tag*, art::Primitive::Type, art::InvokeType)+1736) 07-23 11:35:46.019 1640 1640 F DEBUG : #13 pc 00000000001ae031 /system/lib64/libart.so (art::CheckJNI::CallObjectMethodV(_JNIEnv*, _jobject*, _jmethodID*, __va_list_tag*)+33) 07-23 11:35:46.019 1640 1640 F DEBUG : #14 pc 000000000004555d /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonodroid.so (_JNIEnv::CallObjectMethod(_jobject*, _jmethodID*, ...)+157) 07-23 11:35:46.019 1640 1640 F DEBUG : #15 pc 000000000003beb5 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonodroid.so (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+69) 07-23 11:35:46.019 1640 1640 F DEBUG : #16 pc 00000000001e8585 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.019 1640 1640 F DEBUG : #17 pc 00000000001e7020 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.019 1640 1640 F DEBUG : #18 pc 00000000001d8fb5 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.019 1640 1640 F DEBUG : #19 pc 00000000001d6961 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.019 1640 1640 F DEBUG : #20 pc 00000000000e5f19 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.019 1640 1640 F DEBUG : #21 pc 00000000002a96c6 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so (mono_runtime_invoke_checked+86) 07-23 11:35:46.019 1640 1640 F DEBUG : #22 pc 00000000002b202e /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #23 pc 000000000026cb84 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #24 pc 000000000027615a /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #25 pc 00000000001e8618 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #26 pc 00000000001e7066 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #27 pc 00000000001d8fb5 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #28 pc 00000000001d6961 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #29 pc 00000000000e5f19 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : #30 pc 00000000002a96c6 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so (mono_runtime_invoke_checked+86) 07-23 11:35:46.020 1640 1640 F DEBUG : dotnet#31 pc 00000000002c0713 /data/app/com.microsoft.maui.essentials.devicetests-1/lib/x86_64/libmonosgen-2.0.so 07-23 11:35:46.020 1640 1640 F DEBUG : dotnet#32 pc 0000000000084eee /system/lib64/libc.so (__pthread_start(void*)+46) 07-23 11:35:46.020 1640 1640 F DEBUG : dotnet#33 pc 00000000000296eb /system/lib64/libc.so (__start_thread+11) 07-23 11:35:46.020 1640 1640 F DEBUG : dotnet#34 pc 000000000001ce55 /system/lib64/libc.so (__bionic_clone+53) 07-23 11:35:46.179 1640 1640 F DEBUG : 07-23 11:35:46.179 1640 1640 F DEBUG : Tombstone written to: /data/tombstones/tombstone_00 After some investigation, we think this was introduced in 35f41dc. I could reproduce the issue in a simple test case: [Test] public void PutAndGetManyValues () { for (int i = 0; i < Count; i++) { using var prefs = GetPreferences (); using var editor = prefs.Edit (); editor.PutString ("key" + i, "value" + i); editor.Apply (); } for (int i = 0; i < Count; i++) { using var prefs = GetPreferences (); Assert.AreEqual ("value" + i, prefs.GetString ("key" + i, null)); } } Which also crashed with: 07-24 09:39:02.615 4623 4638 I NUnit : SharedPreferencesTest 07-24 09:39:02.615 4623 4638 I NUnit : PutAndGetManyValues 07-24 09:39:02.719 4623 4638 F art : art/runtime/indirect_reference_table.cc:115] JNI ERROR (app bug): local reference table overflow (max=512) I updated `TypeManager` to use a `try-finally` block, such as: JniObjectReference typeClass = default; JniObjectReference handleClass = default; try { //... } finally { JniObjectReference.Dispose (ref handleClass); JniObjectReference.Dispose (ref typeClass); } And it appears the test case now passes on API 23 emulators. Hoping this will also fix .NET MAUI.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bumps manifest-merger from 30.2.0 to 30.2.1.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)