Repository navigation
Game crashes in libmonodroid.so Java_mono_android_Runtime_init #1673
Description
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/MultiDex(14583): VM with version 2.1.0 has multidex support
I/MultiDex(14583): install
I/MultiDex(14583): VM has multidex support, MultiDex support library is disabled.
W/linker(14583): libmonodroid.so: unused DT entry: type 0x6ffffffe arg 0x5778
W/linker(14583): libmonodroid.so: unused DT entry: type 0x6fffffff arg 0x2
...
W/monodroid(14583): Trying to load sgen from: /data/app/<package_name>-1/lib/arm/libmonosgen-2.0.so
W/linker(14583): libmonosgen-2.0.so: unused DT entry: type 0x6ffffffe arg 0x13828
W/linker(14583): libmonosgen-2.0.so: unused DT entry: type 0x6fffffff arg 0x3
A/libc(14583): Fatal signal 11 (SIGSEGV), code 2, fault addr 0x3d6c4ade in tid 14583
I/DEBUG(2217): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG(2217): Build fingerprint: 'samsung/lt03wifixx/lt03wifi:5.1.1/LMY47X/P600XXUDQA1:user/release-keys'
I/DEBUG(2217): Revision: '5'
I/DEBUG(2217): ABI: 'arm'
I/DEBUG(2217): pid: 14583, tid: 14583, name: >>> <package_name> <<<
I/DEBUG(2217): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x3d6c4ade
I/DEBUG(2217): r0 b4441600 r1 3d6c4ade r2 00000384 r3 00000000
I/DEBUG(2217): r4 00000404 r5 b464a2f8 r6 00000404 r7 0000ffff
I/DEBUG(2217): r8 00000000 r9 00000000 sl 00000004 fp 00000404
I/DEBUG(2217): ip b6de5648 sp beb335f8 lr b348f421 pc b6d8e4a0 cpsr 20070010
I/DEBUG(2217): backtrace:
I/DEBUG(2217): #00 pc 000134a0 /system/lib/libc.so (__memcpy_base+96)
I/DEBUG(2217): #01 pc 0000841d /data/app/<package_name>-1/lib/arm/libmonodroid.so
I/DEBUG(2217): #02 pc 0001177b /data/app/<package_name>-1/lib/arm/libmonodroid.so
I/DEBUG(2217): #03 pc 00007c43 /data/app/<package_name>-1/lib/arm/libmonodroid.so (monodroid_embedded_assemblies_register_from+142)
I/DEBUG(2217): #04 pc 0000d181 /data/app/<package_name>-1/lib/arm/libmonodroid.so
I/DEBUG(2217): #05 pc 0000ca25 /data/app/<package_name>-1/lib/arm/libmonodroid.so (Java_mono_android_Runtime_init+7532)
I/DEBUG(2217): #06 pc 00324f17 /data/dalvik-cache/arm/data@app@<package_name>-1@base.apk@classes.dex
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
Activity
jonpryor commentedon May 11, 2018
It would be interesting if you enabled assembly logging:
This will cause
gather_bundled_assemblies_from_apk()to print out various log messages related to looking for assemblies within the.apk.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
((const char*) info->area)+ *offsetexpression may be problematic, but I'm not entirely sure. Overall, it should be safe, unlessmonodroid/jni/zip/unzip.cwill try to read past the end of the "stream", which actually appears possible: https://github.com/xamarin/xamarin-android/blob/f5412f0efcabec586a02e75938b547e61e889c11/src/monodroid/jni/zip/unzip.c#L365-L370When
((BUFREADCOMMENT+4) < (uSizeFile-uReadPos)is true -- meaning the current read position is < 4 bytes from the file size -- it'll try to read at least 4 bytes, which may very well be past the end of the file.We should fix that, but I don't know if that'll fix your crash.
(We should probably also start using
long longinstead ofint, but I also don't know if that'll do anything with your crash.)huy2368 commentedon May 12, 2018
Hi Jonathan
I turned on monolog, made two testcases and got some logs below. Please take a look on it
undoable.txt
runnable.txt
jonpryor commentedon May 16, 2018
Thank you for the
debug.mono.log=assemblyoutput.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
startvalue is the result of calling mmap(2), which is0xffffffff, which is the value ofMAP_FAILED. Ergo,mmap()is failing....and we weren't doing any error checking around that. (Though I'm not sure what error checking we could do around that; if
mmap()fails, there is currently no fallback path for process startup to find the assemblies to execute.)Also weird is the
lenvalue of1033987912, or the comma-inserted value of 1,033,987,912. Your "986MB".apkis over 1GB in size, once installed onto the device.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
mmapto actually load the.apkinto the process address space. (Not RAM, mind you; just into the process' address space.)Furthermore, I can't think of an easy workaround. Using
$(BundleAssemblies)=True sounded plausible, except that we always callgather_bundled_assemblies()/monodroid_embedded_assemblies_register_from(), even when assemblies are bundled: https://github.com/xamarin/xamarin-android/blob/50bda06ca0d8c74dd950420b84323f16fcbb7002/src/monodroid/jni/monodroid-glue.c#L2681Perhaps you can use
.obbfiles, possibly by using the Xamarin.Google.Android.Vending.Expansion.Downloader NuGet package (documentation).Fix crash with big apks on assembly registration
[monodroid] mmap files separately, not the entire apk (#2570)
jonpryor commentedon Jan 3, 2019
This fix will not be part of the forthcoming d16-0 P2 release, but I do want to include this in P3.
[monodroid] mmap files separately, not the entire apk (#2570)