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

Lollipop WebView crash encrypted Realms #1008

Closed
NirpE opened this issue Apr 2, 2015 · 30 comments

Comments

@NirpE
Copy link

commented Apr 2, 2015

For some weird reason Realm is crashing with Lollipop (Android 5.x) using encrypted database and CookieManager. Can you check if you get any explanation for this.

If I remove Realm from the scope or only remove db encryption it doesn't crash.

Using Realm: compile 'io.realm:realm-android:0.80.1-SNAPSHOT'

Need to have like 15-20 Realm classes with 15 string members each.

Here is minimum code sample to reproduce the crash.

private void makeRealmCrash() {
    final String dbName = "realm_crash";
    final String key = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";

    Realm.deleteRealmFile(MainActivity.this, dbName);

    for (int i = 0; i < 10; i++) {
        final int ii = i;
        new AsyncTask<Void, Void, Void>() {

            @Override
            protected Void doInBackground(Void... params) {
                Realm r = Realm.getInstance(getApplicationContext(), dbName, key.getBytes());

                try {
                    Thread.currentThread().sleep(ii * 25);
                } catch (Exception e) {
                    e.printStackTrace();
                }

                r.close();

                return null;
            }

            @Override
            protected void onPostExecute(Void aVoid) {
                super.onPostExecute(aVoid);

                CookieManager.getInstance();
            }
        }.execute();
    }
}

04-07 15:38:10.339 7639-7674/com.test.testing A/libc﹕ Fatal signal 11 (SIGSEGV), code -6, fault addr 0x1dd7 in tid 7674 (AsyncTask #2)
04-07 15:38:10.441 29379-29379/? I/DEBUG﹕ *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
04-07 15:38:10.441 29379-29379/? I/DEBUG﹕ Build fingerprint: 'google/hammerhead/hammerhead:5.0.1/LRX22C/1602158:user/release-keys'
04-07 15:38:10.441 29379-29379/? I/DEBUG﹕ Revision: '11'
04-07 15:38:10.441 29379-29379/? I/DEBUG﹕ ABI: 'arm'
04-07 15:38:10.441 29379-29379/? I/DEBUG﹕ pid: 7639, tid: 7674, name: AsyncTask #2 >>> com.test.testing <<<
04-07 15:38:10.441 29379-29379/? I/DEBUG﹕ signal 11 (SIGSEGV), code -6 (SI_TKILL), fault addr 0xa220603c
04-07 15:38:10.447 29379-29379/? I/DEBUG﹕ r0 a11ff2e0 r1 a11ff238 r2 afa38108 r3 00000000
04-07 15:38:10.447 29379-29379/? I/DEBUG﹕ r4 a11ff2e0 r5 a2206038 r6 a11ff238 r7 affdde2c
04-07 15:38:10.447 29379-29379/? I/DEBUG﹕ r8 b1217000 r9 b1217030 sl 00003038 fp b1217040
04-07 15:38:10.447 29379-29379/? I/DEBUG﹕ ip 00000000 sp a11ff220 lr aff74213 pc aff73f2a cpsr 800b0030
04-07 15:38:10.448 29379-29379/? I/DEBUG﹕ backtrace:
04-07 15:38:10.448 29379-29379/? I/DEBUG﹕ #00 pc 00060f2a /data/app/com.test.testing-1/lib/arm/libtightdb-jni.so
04-07 15:38:10.448 29379-29379/? I/DEBUG﹕ #01 pc 0006120f /data/app/com.test.testing-1/lib/arm/libtightdb-jni.so

@cmelchior cmelchior self-assigned this Apr 7, 2015

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

Hi @NirpE
I can't reproduce your crash using neither a Nexus 5 or Nexus 7 with Android 5.1.
What hardware/emulator are you using to cause the crash?

@cmelchior cmelchior removed their assignment Apr 7, 2015

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

At least reproduces with Motorola Nexus 6 (5.1.0), I will get more devices to test and report you back soon.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

Also, if you can create a standalone example that causes the crash that would be great as well. It might depend on what the rest of the app is doing at the same time.

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

Can you test Nexus 5 with screen pattern lock enabled?

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

It was already enabled when I tested it. I tested your method by adding it to our introExample project with the following onCreate method

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_realm_basic_example);
        rootLayout = ((LinearLayout) findViewById(R.id.container));
        rootLayout.removeAllViews();
        makeRealmCrash();
    }
@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

I will inform you soon what steps needed for Nexus 5.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

Hi @NirpE
I am still not able to reproduce it even with an new empty project. Does you project have any model classes? If not, that is what is causing the crash. Right now the internals of Realm expect the annotation processor to run to create some internal files. These files will not be generated if there isn't any model classes. It is tracked here: #860 and should be solved by this PR: #938

If not, have you tried refreshing your dependencies in case you are hitting an old cached SNAPSHOT?

./gradlew clean assembleDebug --refresh-dependencies
@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

Hello, I am still trying to find necessary changes to hello world project. I do have model classes, so it's not related to that.

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

Can you try if it reproduces by making 15 RealmClasses which all have @PrimaryKey and like 15 String members?

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

Hi @NirpE. It would be easier if you could just zip the project that fails on your end? If you want to keep it private you can send it to help@realm.io

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

I zipped it, added .txt because gmail wasn't sending it with .zip type. Please inform me if it reproduces with that project.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

Hi @NirpE
Thank you very much for the project. It reproduces on my end now as well.

  • Nexus 5 with Android 5.1 crashes.
  • Nexus 7 with Android 5.0.2 crashes.
  • Genymotion with 4.4.4 runs without problems.
  • Emulator (x86_64) with Android 5.0.1 runs without problems
  • Emulator (arm-v7a) with Android 5.01 runs without problems.

@cmelchior cmelchior added T-Bug and removed Investigate labels Apr 7, 2015

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

That's good thing. This one was super tricky to find, hopefully the reason is in Realm instead of platform.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2015

What is really strange is that the crash goes away if you either

  • disable encryption
  • remove the call to CookieManager.getInstance()

We will dig into this.

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 7, 2015

Yep, also didnt find anything about SIGSEGV with code -6. Like this is the first time
its ever happening.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2015

Realm currently loads OpenSSL on the device when using encrypted Realms, and we suspect that CookieManager might be doing something similar, but the interaction is not clear atm. We will keep you posted.

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 8, 2015

From the small trace it seems libtightdb-jni.so causes the crash, have you found the crashing line with ndk-stack/addr2line or similar tools ?

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2015

Hi @NirpE
I have created a separate branch with your test code + my findings so far. I am impressed you where actually able to reproduce this as you only have to change the code very little to not see the bug at all.

libtightdb-jni.so is just our JNI layer which calls directly down to our core database which normally don't ship with symbols included, so ndk-stack is not that helpful in this case. However we have some other debug utils in place to help with this.

https://github.com/realm/realm-java/tree/cm-bug-crash-cookiemanager

It will require some digging in the core database to find the source of this, but I will keep you posted.

@anlaital

This comment has been minimized.

Copy link

commented Apr 10, 2015

@cmelchior Is it possible to get this prioritised high since it's the only thing preventing us from releasing on Android?

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2015

Hi @anlaital
We will try to address this as fast as possible, but as the error only happens in multithreaded scenarios, you can imagine debugging those.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2015

@softkot found a much simpler reproducible test for what looks like the same issue. His test project has been moved to the test branch: https://github.com/realm/realm-java/tree/cm-bug-crash-cookiemanager/experimental/webviewCrash

@NirpE

This comment has been minimized.

Copy link
Author

commented Apr 11, 2015

I believe under WebView the same CookieManager instance is being created at some point. Can you test if workaround calling CookieManager getInstance in the Activity onCreate before doing anything else works in that project?

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2015

Yes, that removes the crash, just like in your project.

@cmelchior cmelchior changed the title Crash on Lollipop Lollipop WebView crash encrypted Realms Apr 11, 2015

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

Hi @NirpE and @softkot
It seems to be related to the version of the Android System WebView. We can provoke crashes on version 40, but if you downgrade to version 39 (which ships with the system image) it works fine.

We are still trying to figure out what exactly is causing the crash though.

@softkot

This comment has been minimized.

Copy link

commented Apr 13, 2015

Hi @cmelchior, right and that was noticed in my #1023 initial report.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2015

Ah sorry. I thought you where referring to older versions of Android with that. At least we are on the same page now :)

@tgoyne

This comment has been minimized.

Copy link
Member

commented Apr 15, 2015

This appears to be a Chromium bug: initializing a CookieManager or WebView is installing a signal handler for SIGSEGV that doesn't forward signals it doesn't handle correctly (it calls the previously registered handler, but with garbage arguments). I don't think there's anything totally reliable we can do to work around this, but it does at least mean that the workaround of calling CookieManager.getInstance() before doing anything with Realm actually is working around the problem (since it means that it's our signal handler forwarding to Chromium's rather than the other way around) and isn't just working by coincidence.

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2015

For reference: We have created this bug report on the Chromium project: https://code.google.com/p/chromium/issues/detail?id=476831

@cmelchior cmelchior added P2 Blocked and removed P2 labels Apr 15, 2015

@cmelchior cmelchior assigned bjchrist and unassigned bjchrist Apr 15, 2015

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2015

In either case, this is not something the Java API can fix. Instead we should add it to our FAQ with the current work around.

@cmelchior cmelchior added P1 and removed backlog Blocked labels Apr 15, 2015

@timanglade timanglade closed this Apr 22, 2015

@timanglade timanglade removed the PR label Apr 22, 2015

@cmelchior

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2015

Just to update on this. Chromium fixed this bug: https://code.google.com/p/chromium/issues/detail?id=483399 and it was released to the Play Store yesterday as part of 43.0.2357.90. So users seeing this problem should now be able to update their way out of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.