Game crashes in libmonodroid.so Java_mono_android_Runtime_init #1673
Assignees
Milestone
Comments
|
It would be interesting if you enabled assembly logging: This will cause From the backtrace we see that memcpy(3) is called, so we're probably crashing here: https://github.com/xamarin/xamarin-android/blob/f5412f0efcabec586a02e75938b547e61e889c11/src/monodroid/jni/embedded-assemblies.c#L254 That doesn't explain why it's crashing, though. :-( My guess would be that we're overflowing an integer, and my gut thinks the When We should fix that, but I don't know if that'll fix your crash. (We should probably also start using |
|
Hi Jonathan
|
|
Thank you for the This is weird: The above message is from here: https://github.com/xamarin/xamarin-android/blob/50bda06ca0d8c74dd950420b84323f16fcbb7002/src/monodroid/jni/embedded-assemblies.c#L374-L378 The ...and we weren't doing any error checking around that. (Though I'm not sure what error checking we could do around that; if Also weird is the I thus have an answer: your app is too big -- when running on 32-bit devices -- for our normal app startup code path, because it's too big for Furthermore, I can't think of an easy workaround. Using Perhaps you can use |
mathieubourgeois
added a commit
to gameloft/xamarin-android
that referenced
this issue
Dec 24, 2018
Xamarin.Android, on launch, needs to do a pass through the files in the apk to register assemblies (.dll/.exe), dll configuration files (.config), symbols (.mdb/.pdb) and bindings typemaps (.jm/.mj). To do this pass, the process was to mmap the apk in the process' adress space, then grab the memory offsets for each file and register them on each system as needed. However, mmap-ing the whole apk has the consequence of taking potentially a lot of adress space. Considering it is legal to have a big apk (even though you can't submit an apk of more than 100 Mb to the Play Store, you can still submit it somewhere else, or embed your data in the apk during the development process for simplicity's sake), having an apk of about ~800 Mb in size automatically crashes on launch in armeabi-v7a because it can't find a contiguous 800 Mb block of adress space. The following log is usually found when that issue hits: `I/monodroid-assembly(14915): start: 0xffffffff end: 0x3da16747 len: 1033987912 apk: /data/app/<package_name>-1/base.apk` However, we don't need to mmap the whole apk, only the files that we are actually registering. Therefore, refactor the registration code to not mmap the whole apk. Instead, open the apk regularly, then when we actually need one of the entries, mmap the area of the file in the apk from a page-aligned offset and use those mmap sections for registration instead. Fixes dotnet#1673
jonpryor
pushed a commit
that referenced
this issue
Jan 3, 2019
Fixes: #1673 During process startup, Xamarin.Android looks through the `.apk` for various files to register within mono and itself, including: * Assemblies (`.dll`/`.exe`) * Assembly configuration files (`.dll.config`) * Debug symbols (`.mdb`/`.pdb`) * Type Map files (`.jm`/`.mj`) Such files are stored *uncompressed* within the `.apk` and are aligned on 4-byte boundaries via `zipalign`. In order to *use* these files, the entire `.apk` would be **mmap**(2)'d into the process address space, so that e.g. the assemblies could be registered directly with mono without copying the assembly contents "elsewhere" (e.g. disk, RAM), and instead would be demand-paged *into* RAM from disk as needed. There is an unfortunate downside to this approach: `.apk` files can contain lots of content which *isn't* of interest to mono/etc., such as Android Assets and Resources (large MP4 video files?), and the "`mmap()` everything!" approach means that all this *unneeded* data is *also* `mmap()`ed into the process address space. Which is what Issue #1673 triggered: a 930MB `.apk` file with lots of "game assets" could not load within a 32-bit address space, because there wasn't 930MB of free contiguous address space to use: I/monodroid-assembly(14915): start: 0xffffffff end: 0x3da16747 len: 1033987912 apk: /data/app/<package_name>-1/base.apk A/libc(14915): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x3da16343 in tid 14915 `mmap()`ing the whole `.apk`, while effective, is overkill. Update `gather_bundled_assemblies_from_apk()` so that instead of loading the entire `.apk` with one `mmap()` call, we instead use separate `mmap()` calls for each distinct file of interest within the `.apk` -- on OS page-aligned memory -- so that we don't excessively use process address space.
|
This fix will not be part of the forthcoming d16-0 P2 release, but I do want to include this in P3. |
jonpryor
pushed a commit
that referenced
this issue
Jan 17, 2019
Fixes: #1673 During process startup, Xamarin.Android looks through the `.apk` for various files to register within mono and itself, including: * Assemblies (`.dll`/`.exe`) * Assembly configuration files (`.dll.config`) * Debug symbols (`.mdb`/`.pdb`) * Type Map files (`.jm`/`.mj`) Such files are stored *uncompressed* within the `.apk` and are aligned on 4-byte boundaries via `zipalign`. In order to *use* these files, the entire `.apk` would be **mmap**(2)'d into the process address space, so that e.g. the assemblies could be registered directly with mono without copying the assembly contents "elsewhere" (e.g. disk, RAM), and instead would be demand-paged *into* RAM from disk as needed. There is an unfortunate downside to this approach: `.apk` files can contain lots of content which *isn't* of interest to mono/etc., such as Android Assets and Resources (large MP4 video files?), and the "`mmap()` everything!" approach means that all this *unneeded* data is *also* `mmap()`ed into the process address space. Which is what Issue #1673 triggered: a 930MB `.apk` file with lots of "game assets" could not load within a 32-bit address space, because there wasn't 930MB of free contiguous address space to use: I/monodroid-assembly(14915): start: 0xffffffff end: 0x3da16747 len: 1033987912 apk: /data/app/<package_name>-1/base.apk A/libc(14915): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x3da16343 in tid 14915 `mmap()`ing the whole `.apk`, while effective, is overkill. Update `gather_bundled_assemblies_from_apk()` so that instead of loading the entire `.apk` with one `mmap()` call, we instead use separate `mmap()` calls for each distinct file of interest within the `.apk` -- on OS page-aligned memory -- so that we don't excessively use process address space.
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi guys
I got a strange issue need your support
We have been developing a game.
We use Xamarin 8.3.99, NDK15c, SDK build tools 27.0.3.
I have an apk run on Samsung Note 10.1 but after I put all data (~30k files - over 930Mb) without compressing () into assets in apk, game crashes
Here is the native log. Im sorry, I will hide game package name.
I dont know whether there is any limitation from Xamarin with big apk (~960Mb).
Could you guys give us some suggestions for this issue?
Thanks
The text was updated successfully, but these errors were encountered: