Realm-java: Realm 3.4.0 SIGNAL 11

Created on 17 Jul 2017 · 25Comments · Source: realm/realm-java

We recently upgraded our app from Realm 3.1.4 to Realm 3.4.0.
Everything appeared to be fine in QC and Staging tests, but when we released to production we saw our errors go through the roof. Unfortunately we still can't reproduce the issue in QC or Staging, and we don't have support for native crashes enabled in crashlytics. From the play console, we have:

This appears to be happening in our arm builds (armeabi-v7a and arm64-v8a).

arm64-v8a:
backtrace:
native: pc 0000000000174d40 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 0000000000175898 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 000000000003fefc /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001cf6f0 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001cf74c /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 0000000000083cc4 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 000000000007ba44 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001c7cec /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001c8184 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001951e8 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001c8184 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001951e8 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001c7c1c /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 0000000000195f0c /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001a5468 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000001a5550 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000000f312c /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000000efb4c /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000000efe7c /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 0000000000106da8 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 0000000000106e84 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 00000000002186f8 /data/app/com.ourapp.app-1/lib/arm64/librealm-jni.so
native: pc 000000000006904c /system/lib64/libc.so (_ZL15__pthread_startPv+196)
native: pc 000000000001e2b8 /system/lib64/libc.so (__start_thread+16)

armeabi-v7a:
backtrace:
native: pc 00000000000e332a /data/app/com.ourapp.app-2/lib/arm/librealm-jni.so

HELP!!

Blocked O-Community T-Bug-Crash

Source

mandrachek

Most helpful comment

@Zhuinden I think the app has only 1 process using Realm. Since he is using encryption which is not supported for multi-processes.

beeender on 18 Jul 2017

🎉1 👍1

All 25 comments

Hi @mandrachek Are you showing all the information from the Play Store console because the error messages seems to have been cut off?

cmelchior on 17 Jul 2017

Also, do you use encryption?

beeender on 17 Jul 2017

Parsed backtrace:

execute_native_thread_routine
/s/ndk-toolchain/src/gcc/gcc-4.9/libstdc++-v3/src/c++11/thread.cc:84
std::thread::_Impl<std::_Bind_simple<realm::_impl::ExternalCommitHelper::DaemonThread::DaemonThread()::{lambda()#1} ()> >::_M_run()
external_commit_helper.cpp:?
realm::_impl::ExternalCommitHelper::DaemonThread::listen()
:?
realm::_impl::RealmCoordinator::on_change()
:?
realm::_impl::RealmCoordinator::run_async_notifiers()
:?
realm::_impl::ResultsNotifier::run()
:?
realm::Query::find_all(unsigned long, unsigned long, unsigned long)
:?
realm::Query::find_all(realm::TableViewBase&, unsigned long, unsigned long, unsigned long) const
:?
realm::Query::aggregate_internal(realm::Action, realm::DataType, bool, realm::ParentNode*, realm::QueryStateBase*, unsigned long, unsigned long, realm::SequentialGetterBase*) const
:?
realm::ParentNode::aggregate_local(realm::QueryStateBase*, unsigned long, unsigned long, unsigned long, realm::SequentialGetterBase*)
:?
realm::OrNode::find_first_local(unsigned long, unsigned long)
:?
realm::ParentNode::find_first(unsigned long, unsigned long)
:?
realm::OrNode::find_first_local(unsigned long, unsigned long)
:?
realm::ParentNode::find_first(unsigned long, unsigned long)
:?
realm::ExpressionNode::find_first_local(unsigned long, unsigned long)
:?
realm::Compare<realm::Equal, realm::StringData, realm::Subexpr, realm::Subexpr>::find_first(unsigned long, unsigned long) const
:?
realm::SimpleQuerySupport<realm::StringData>::evaluate(unsigned long, realm::ValueBase&)
:?
realm::StringData realm::Table::get<realm::StringData>(unsigned long, unsigned long) const
:?
realm::StringEnumColumn::get(unsigned long) const
:?
realm::BpTree<long>::get(unsigned long) const
:?
realm::BpTreeNode::get_bptree_leaf(unsigned long) const
:?
(anonymous namespace)::find_bptree_child(long, unsigned long, realm::Allocator const&)
bptree.cpp:?

beeender on 17 Jul 2017

Yes, we use encryption. And yes, those are the complete logs from the play store (app name changed). Probably not as good as crashlytics, but it's what we've got.

I've sent an email to [email protected] with a link to the app in the play store and screenshots from the play console.

mandrachek on 17 Jul 2017

@mandrachek The links you send to [email protected] are two images ... and they are quite long ... can you send the REAL images in the mail instead ? :) thanks!

beeender on 17 Jul 2017

What's a REALM image? I can't reproduce this issue myself.
I sent a link to the play store and two png screenshots of the crash on the play store (so you can see that what I posted is indeed what the play store has provided in terms of the crash log).

mandrachek on 17 Jul 2017

@mandrachek never mind, i am stupid. We got the images.

beeender on 17 Jul 2017

INTERNAL NOTE: More information can be found https://secure.helpscout.net/conversation/398604756/10646/?folderId=366141

beeender on 17 Jul 2017

Is it possible to downgrade back to 3.1.4? Or will the local databases be hosed?

mandrachek on 17 Jul 2017

You can also try updating to Realm 3.5.0, there were some bugs fixed, primarily related to queries that are isEmpty(), isNotEmpty(), isNull() and isNotNull().

Zhuinden on 17 Jul 2017

The error in question though is in our notification system. It doesn't look related to the bug fixes for those methods.

cmelchior on 17 Jul 2017

@mandrachek I believe it is yes, but we are verifying it with our core people. In general, it is safe to downgrade versions that did not involve file format change, and by looking at https://github.com/realm/realm-core/blob/master/CHANGELOG.md there doesn't appear to be any.

I'll return with a more definitive answer.

cmelchior on 17 Jul 2017

@cmelchior thanks - I tested the downgrade locally and didn't see any issues, so pushing a build with realm rolled back shortly (just waiting for jenkins to finish).

@Zhuinden - given that we can't seem to reproduce this issue in QC or Staging, even on devices that are having the issue in production (ugh), I'd rather roll back than try and push ahead.

mandrachek on 17 Jul 2017

Rolled realm back to 3.1.4, and it appears to have fixed the issue.

mandrachek on 17 Jul 2017

👍2

@mandrachek Do you ever user Realm.compact() in your code?

beeender on 18 Jul 2017

@beeender During realm initialization, we call compactRealm()

            Realm.init(applicationContext);

            RealmConfiguration realmConfiguration = new RealmConfiguration.Builder()
                    .name(realmFile)
                    .encryptionKey(key.getEncoded())
                    .schemaVersion(BuildConfig.VERSION_CODE)
                    .deleteRealmIfMigrationNeeded()
                    .build();

            Realm.compactRealm(realmConfiguration);

            Realm.setDefaultConfiguration(realmConfiguration);

mandrachek on 18 Jul 2017

@mandrachek thanks! BTW, i created a core issue for this. You may want to follow that as well. https://github.com/realm/realm-core/issues/2746

beeender on 18 Jul 2017

@mandrachek is this in Application.onCreate()?

Can you guarantee that the app has only 1 process?

Zhuinden on 18 Jul 2017

@Zhuinden I think the app has only 1 process using Realm. Since he is using encryption which is not supported for multi-processes.

beeender on 18 Jul 2017

🎉1 👍1

Ah yes, you are right.

Zhuinden on 18 Jul 2017

Yes, the application only has one process. Plenty of threads, but only one process. No, this code is not directly in onCreate. It is called in a synchronized method on a helper class that is only called under two circumstances.

1) If the application has an Android system account, then it's called in Application.onCreate().
2) If there is no user account, we delay calling it until immediately after the user account is created.

(The realmFile and the key are dependent on the currently logged in account).

mandrachek on 18 Jul 2017

👍1

Adding T:Help to assist tracking.

bmeike on 25 Jul 2017

Hey @mandrachek ,
Do you have any objection to closing this issue and tracking the bug in https://github.com/realm/realm-core/issues/2746 ? It seems to have more/better information.
Thanks,
-blake

bmeike on 28 Jul 2017

@bmeike I think it is better to keep this open in the java side as well. Since most java users won't go to core repo to find the opening bugs. Keeping it open make it easier for other users who may have the same issue to know that this is not fixed.

beeender on 28 Jul 2017

https://github.com/realm/realm-core/issues/2746 is closed.

beeender on 23 Aug 2017

Was this page helpful?

0 / 5 - 0 ratings