Unity 2019.x IL2CPP crash on Android 8

Unity Engine
,
1

I recently updated Unity to 2019.1.x from 2018.x, and now I can no longer deploy to Android 8 with an IL2CPP release build. The app crash immediately upon launch with errors like this:

FATAL EXCEPTION: UnityMain
Process: com.whatever.bestappever, PID: 11624
java.lang.Error: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000008
Build fingerprint: 'samsung/gts3lwifixx/gts3lwifi:8.0.0/R16NW/T820XXU2BRL1:user/release-keys'
Revision: '5'
pid: 11624, tid: 11642, name: UnityMain >>> com.whatever.bestappever <<<
r0 00000002 r1 00000001 r2 00000000 r3 00004552
r4 c481b170 r5 c456b000 r6 00000000 r7 c6c8e788
r8 00c4b348 r9 00000001 sl 00c4b354 fp c6e7dbe8
ip e9654d5c sp c6e7dba8 lr c5463354 pc c5463330 cpsr e871bd10
at libil2cpp.001d4330(Native Method)
at libil2cpp.001d4350(Native Method)

I cannot recall that I had this problem when using Unity 2018.x. The app seems to work OK on my galaxy Tab S5e (Android 9) but there are problems on my Galaxy Tab S3 (Android 8), like this:

  • Mono build (Release and Debug) works.
  • IL2CPP Debug build works.
  • IL2CPP Release build crash on launch with the error mentioned above.

I have tried with variolous stripping levels and with/without ARM64 support; everything fails when a release build is deployed to my Android 8 device, everything works when deployed to my Android 9 device. I haven’t tried with any other devices.

1 Like
2

Which version of Unity do you use? We had a bug like this, but I think it was fixed.

3

Sorry, I should have mentioned that. I currently use 2019.1.1.f1

4

Sounds like another missed case then. Could you tell the exact phone model and Android version on it?
Hopefully we will be able to reproduce and fix it then.

5

Samsung Galaxy Tab S3. SM-T820.
Android 8.0.0

6

Hey GuruGurra, do you get this crash with newly created empty project? If not, could you submit a bug report with project where it reproduces and write number of the bug report here?

7

I haven’t been able to reproduce the problem with a new project, but need to adjust some of the claims I did before. This is very weird.

  • There is no difference between Android 8 and 9 as I initially thought, both versions have the same problem.

  • Mono builds work.

  • And now the odd thing: IL2CPP builds (both Debug and Release) fail after the first install but work after a second install(!?)

  • I uninstall any previous installation if present.

  • I install the apk file.

  • I start the app, and it crash. (not just the first time - every time I try to start it…until…)

  • I install the very same apk file again (without doing any uninstall in-between)

  • I start the app, and it works…

4 Likes
8

OK, a theory (that might be rather serious, if I’m right)…

I stripped my app to bare minimum, removed all scenes but one, removed most of the script code and only logged when/if my app started. It doesn’t start. So…the problem isn’t my code.

I believe that the problem is the automatic backup/restore of app data that Android is doing, and that this (restore) breaks IL2CPP in some way (remember: the problem occurs only with IL2CPP). Consider this:

  • I open the App settings and clear cache and app data.
  • I verify that the app folder is empty
  • I uninstall the app.
  • I verify that the app folder is deleted.
  • I install the app.
  • The app crashes upon start.
  • I check the app folder - it contains a number of files. Files that are not created by the current version of the app since all code is removed.

Obviously Android has restored the app folder data from a backup. Among the restored data is an IL2CPP folder with a content that differs from that of a fresh installed app (see below).

  • I configure Android to not restore app data when an app is reinstalled.

  • I uninstall the app.

  • I install the app.

  • I start the app.

  • The app starts without any problems.

  • I check the app folder - it contains only an IL2CPP folder (since the current version of my code doesn’t create any files).

My guess is that the Android auto-restore pushes an IL2CPP folder into the app folder - an IL2CPP folder with a content that is not compatible with the new package. I don’t really know what the folder is used for, but a file compare tells me there are differences between the content that is installed with the apk file and the content that is restored by Android.

This also explain the weird behavior that the app works after a second install since the auto restore isn’t active at the second installation; allowing the “real” IL2CPP folder to be installed by the apk package.

If this theory is correct I guess that more developers than me will be affected by this problem.

9 Likes
9

There is another possible reason, it can be determine via hardcore way:
Go to Unity Editor app and in it’s package locate this file: il2cpp/libil2cpp/os/Android/Image.cpp
It contains a function FindManagedCodeSectionInElfBinary. Modify it by adding some android native logging: Logging  |  Android NDK  |  Android Developers

It could be that the crash is caused by an attempt to read a particular file mapped to memory and the intermittence of the crash comes from the order of files in the list being processed.

10

It looks like this might be the issue.
I had problems with my app crashing on launch (only Release builds downloaded from Google Play crashes). When I disable automatic restore in my phone settings, the app launches. This is pretty bad if it really is the issue.

@Aurimas-Cernius Are you aware of an issue like this?

1 Like
11

Hi there,

We’re facing the exact same issue and to be honest It’s been driving us nuts for the last week.

Hope it’s solved soon cause it’s stopping our whole update roadmap due to being forced to use the IL2CPP in order to meet the google 64 bit demands…

At least we know what’s going on and stop trying crazy thigs here and there.

Thank you GuruGurra for the tip, you have saved some serious amount of sannity today!!

2 Likes
12

No. If this is reliably reproducible, could you report a bug?

13

For me it has only happened sometimes with a version downloaded from Google Play (internal test in my case), and only when auto backup has been active.

It happened pretty consistently with application built with Unity 2019.1.3, and then when I built with 2019.1.4 it seemed like it went away, but when using 2019.1.4, there auto backup did not seem to work either…

I have never had an application stacktrace, only SEGV_MAPERR and SEGV_ACCERR.

I have disabled auto backup and hope that “fixes” the problem.

The only library that does something special that I can think of is the Fullserializer json library (https://github.com/jacobdufault/fullserializer)
Don’t know if it could be some combination of what it does with AOT and auto backup that causes problems. This is pure speculation though, and I don’t know what I am talking about.

14

For us It’s been happening consistently with multiple test devices using the Unity version 2019.1.0f2.

As far as our test goes,It doesn’t matter witch target architecure.
If you have installed the app using the IL2CPP with a previous version of Unity it crashes upon start every single time, before even the splash screen shows up, unless you disable the automatic backup/restore from the device.

1 Like
15

You probably know this, but if you do not need auto backups you can disable it for the app by copying \Editor\Data\PlaybackEngines\AndroidPlayer\Apk\AndroidManifest.xml to \Assets\Plugins\Android\

And adding this to the application tag:
android:allowBackup=“false” tools:replace=“android:allowBackup”

full example:

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.unity3d.player"
    xmlns:tools="http://schemas.android.com/tools"
    android:installLocation="preferExternal">
    <supports-screens
        android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true"
        android:anyDensity="true"/>

    <application
        android:theme="@style/UnityThemeSelector"
        android:icon="@mipmap/app_icon"
        android:label="@string/app_name" android:allowBackup="false" tools:replace="android:allowBackup">
        <activity android:name="com.unity3d.player.UnityPlayerActivity"
                  android:label="@string/app_name">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
            <meta-data android:name="unityplayer.UnityActivity" android:value="true" />
        </activity>
    </application>
</manifest>
13 Likes
16

I’m having the same issue: when I install on my device the first time, it doesn’t work, after I clear data, it works. That’s weird! Any news about the fix?

This is the error in logcat:

2019-05-31 13:07:39.950 24925-24956/? E/CRASH: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0000006f41149fd0
2019-05-31 13:07:39.950 24925-24956/? E/CRASH: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2019-05-31 13:07:39.950 24925-24956/? E/CRASH: Build type ‘Release’, Scripting Backend ‘il2cpp’, CPU ‘arm64-v8a’
2019-05-31 13:07:39.950 24925-24956/? E/CRASH: Build fingerprint: ‘google/taimen/taimen:9/PQ3A.190505.001/5373320:user/release-keys’
2019-05-31 13:07:39.951 24925-24956/? E/CRASH: Revision: ‘rev_10’

17

I am having a similar but different issue. I am using Jenkins to automate my builds but somehow, the resulting binaries seem to be those of previous builds. After extensive research, I found that there were 2 main problems. One of which was the Android backup as mentioned above that keeps restoring binaries from previous app versions.

The other, being the gradle workflow apparently caches compiled binaries if the source was not extensively modified. My project is utilizing the assembly definition extensively due to code organization and team collaboration. That being said, each rapid build is of course, contain little modifications to each library files.
Is there a way to include a clean cache option into the gradle workflow?

18

Additional info: AFAIK, the gradle cache is stored independently of the jenkins workspace. So clearing the workspace was of no help :frowning:

19

We are having the same issue and @GuruGurra 's theory matches all of our suspicions and tests.
Adding allowBackup=false seems to have solved the issue for now, but this means we are removing the backup feature, which is very nice to have :confused:

1 Like
20

Hi @Ara27 , could you give me more details how are you installing the apk? do you have a reproduction case? I am trying to reproduce it but no luck yet.

1 Like