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.

Sign up for GitHub

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

Jump to bottom

terminating with uncaught exception of type realm::NoSuchTable #3701

Closed
finnschiermer opened this issue Apr 29, 2020 · 23 comments
Closed

terminating with uncaught exception of type realm::NoSuchTable #3701

finnschiermer opened this issue Apr 29, 2020 · 23 comments
Labels
T-Bug-Crash

Comments

@finnschiermer
Copy link
Contributor

finnschiermer commented Apr 29, 2020 •
edited by RealmBot
Loading

Partial backtrace data:

2020-04-28 12:55:32.120 9881-9881/? A/DEBUG: Abort message: 'terminating with uncaught exception of type realm::NoSuchTable: No such table exists
    Exception backtrace:
    <backtrace not supported on this platform>'
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x0  0000000000000000  x1  000000000000266d  x2  0000000000000006  x3  0000000000000008
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x4  fefefeff3d6c716e  x5  fefefeff3d6c716e  x6  fefefeff3d6c716e  x7  7f7f7f7f7f7f7f7f
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x8  0000000000000083  x9  46c6fb2ad6e7af90  x10 0000000000000000  x11 fffffffc7ffffbdf
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x12 0000000000000001  x13 000000005ea80ba4  x14 000206e34c6313dc  x15 0000606d0eff6204
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x16 00000078172f22a8  x17 0000007817211954  x18 0000000000000010  x19 0000000000002654
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x20 000000000000266d  x21 0000007779e5fd58  x22 ffffff80ffffffc8  x23 0000007779e5fe10
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x24 0000007779e5fcf0  x25 0000007779e5fd30  x26 0000007789bb58a0  x27 0000000000000005
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     x28 0000007779e62c10  x29 0000007779e5fc60
2020-04-28 12:55:32.120 9881-9881/? A/DEBUG:     sp  0000007779e5fc20  lr  0000007817205084  pc  00000078172050ac
2020-04-28 12:55:32.157 7171-7171/? E/fb4a.WhiteChromeNavBarController: called by fragment NewsFeedFragment
2020-04-28 12:55:32.257 2438-2438/? E/ndroid.systemu: Invalid ID 0x00000000.
2020-04-28 12:55:32.334 9881-9881/? A/DEBUG: backtrace:
2020-04-28 12:55:32.334 9881-9881/? A/DEBUG:     #00 pc 00000000000220ac  /system/lib64/libc.so (abort+116)
2020-04-28 12:55:32.334 9881-9881/? A/DEBUG:     #01 pc 0000000000c9deec  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (abort_message+236)
2020-04-28 12:55:32.334 9881-9881/? A/DEBUG:     #02 pc 0000000000c9e044  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (demangling_terminate_handler()+260)
2020-04-28 12:55:32.334 9881-9881/? A/DEBUG:     #03 pc 0000000000c9af34  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (std::__terminate(void (*)())+12)
2020-04-28 12:55:32.334 9881-9881/? A/DEBUG:     #04 pc 0000000000c9aecc  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (std::terminate()+36)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #05 pc 0000000000166f54  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (__clang_call_terminate+8)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #06 pc 0000000000b86838  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::table::update_from_parent(unsigned long)+616)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #07 pc 0000000000a9f3c4  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::Group::update_refs(unsigned long, unsigned long)+352)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #08 pc 0000000000a9f194  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::Group::remap_and_update_refs(unsigned long, unsigned long, bool)+160)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #09 pc 0000000000ab6da0  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::Transaction::commit_and_continue_as_read()+416)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #10 pc 00000000003a3c1c  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::_impl::RealmCoordinator::commit_write(realm::Realm&)+220)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #11 pc 00000000003400a4  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::realm::commit_transaction()+404)
2020-04-28 12:55:32.335 9881-9881/? A/DEBUG:     #12 pc 00000000004f4d9c  /data/app/io.realm.test-uMCqIDux40BKQiA0letzdA==/lib/arm64/librealm-jni.so (realm::SyncMetadataManager::get_or_make_user_metadata(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const&, std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char>> const&, bool) const+1760)
@cmelchior
Copy link
Contributor

Reproducible on an arm64 device (OnePlus 5T), but not on the x86_64 bit Android emulator. The crash happens here: https://github.com/realm/realm-object-store/blob/yg/ng-sync/src/sync/impl/sync_metadata.cpp#L342

@finnschiermer
Copy link
Contributor Author

finnschiermer commented Apr 29, 2020 •
edited
Loading

Observations:

  • The abort happens in Table::update_from_parent(), which is declared noexcept, due to an exception being thrown.
  • Execption is thrown in key2ndx_checked(), called from get_table(), called from update_from_parent().

It indicates that an invalid table-key is being used to lookup a table accessor. This happens in the flow of updating accessors after a commit_and_continue_as_read(). It should not be possible to have an invalid reference at that point.

@cmelchior
Copy link
Contributor

Fun fact. Nabil tested this on his Nexus6P which is also an Arm64 bit device, where this bug does not manifest.

@RealmBot
Copy link
Collaborator

RealmBot commented May 7, 2020

➤ Finn Andersen commented:

Fun fact. Cannot be reproduced if built without sync support.

@cmelchior
Copy link
Contributor

This might just have been me not porting everything correctly. Because the Sync setup is rather complicated.

@cmelchior
Copy link
Contributor

cmelchior commented May 14, 2020 •
edited
Loading

I ran into this in Core-6 when running some tests:

05-14 16:26:45.877 I/TestRunner( 1328): started: conflictingFieldName_readAndUpdate(io.realm.RealmObjectTests)
05-14 16:26:45.879 I/MonitoringInstr( 1328): Activities that are still in CREATED to STOPPED: 0
05-14 16:26:46.008 F/DEBUG   (  485): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-14 16:26:46.009 F/DEBUG   (  485): Build fingerprint: 'google/bullhead/bullhead:6.0/MDA89E/2296692:user/release-keys'
05-14 16:26:46.009 F/DEBUG   (  485): Revision: 'rev_1.0'
05-14 16:26:46.010 F/DEBUG   (  485): ABI: 'arm64'
05-14 16:26:46.011 F/DEBUG   (  485): pid: 1328, tid: 1348, name: roidJUnitRunner  >>> io.realm.test <<<
05-14 16:26:46.012 F/DEBUG   (  485): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
05-14 16:26:46.221 W/debuggerd64(  485): type=1400 audit(0.0:8301): avc: denied { search } for name="io.realm.test" dev="dm-2" ino=392612 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
05-14 16:26:46.334 E/QCALOG  (  519): [MessageQ] ProcessNewMessage: [LOWI-SERVER] unknown deliver target [OS-Agent]
05-14 16:26:46.381 W/debuggerd64(  485): type=1400 audit(0.0:8302): avc: denied { search } for name="io.realm.test" dev="dm-2" ino=392612 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
05-14 16:26:46.485 F/DEBUG   (  485): Abort message: 'terminating with uncaught exception of type realm::NoSuchTable: No such table exists
05-14 16:26:46.485 F/DEBUG   (  485): Exception backtrace:
05-14 16:26:46.485 F/DEBUG   (  485): <backtrace not supported on this platform>'
05-14 16:26:46.486 F/DEBUG   (  485):     x0   0000000000000000  x1   0000000000000544  x2   0000000000000006  x3   0000000000000000
05-14 16:26:46.486 F/DEBUG   (  485):     x4   0000000000000000  x5   0000000000000001  x6   0000000000000000  x7   0000000000000000
05-14 16:26:46.486 F/DEBUG   (  485):     x8   0000000000000083  x9   fefefeff3d6c716e  x10  7f7f7f7f7f7f7f7f  x11  0101010101010101
05-14 16:26:46.486 F/DEBUG   (  485):     x12  0000000000000095  x13  0000000000000000  x14  0000000000000000  x15  0033e773f0318dfe
05-14 16:26:46.486 F/DEBUG   (  485):     x16  0000007f9638a568  x17  0000007f9631cf9c  x18  00000000ffffffe0  x19  0000007f7a5ff500
05-14 16:26:46.486 F/DEBUG   (  485):     x20  0000007f7a5ff440  x21  0000000000000000  x22  0000000000000006  x23  0000007f7a5fee80
05-14 16:26:46.486 F/DEBUG   (  485):     x24  0000007f7a5fed60  x25  0000007f7a5feda0  x26  0000007f96319000  x27  0000007f919bce60
05-14 16:26:46.486 F/DEBUG   (  485):     x28  0000000000001000  x29  0000007f7a5fec20  x30  0000007f9631a858
05-14 16:26:46.487 F/DEBUG   (  485):     sp   0000007f7a5fec20  pc   0000007f9631cfa4  pstate 0000000020000000
05-14 16:26:46.507 F/DEBUG   (  485): 
05-14 16:26:46.507 F/DEBUG   (  485): backtrace:
05-14 16:26:46.507 F/DEBUG   (  485):     #00 pc 000000000006afa4  /system/lib64/libc.so (tgkill+8)
05-14 16:26:46.507 F/DEBUG   (  485):     #01 pc 0000000000068854  /system/lib64/libc.so (pthread_kill+68)
05-14 16:26:46.508 F/DEBUG   (  485):     #02 pc 0000000000023838  /system/lib64/libc.so (raise+28)
05-14 16:26:46.508 F/DEBUG   (  485):     #03 pc 000000000001dfd8  /system/lib64/libc.so (abort+60)
05-14 16:26:46.508 F/DEBUG   (  485):     #04 pc 0000000000af6eac  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (abort_message+236)
05-14 16:26:46.508 F/DEBUG   (  485):     #05 pc 0000000000af7004  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (demangling_terminate_handler()+260)
05-14 16:26:46.508 F/DEBUG   (  485):     #06 pc 0000000000af3ef4  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (std::__terminate(void (*)())+12)
05-14 16:26:46.508 F/DEBUG   (  485):     #07 pc 0000000000af37fc  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (__cxa_rethrow+196)
05-14 16:26:46.508 F/DEBUG   (  485):     #08 pc 00000000003829d8  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (realm::_impl::ExternalCommitHelper::DaemonThread::DaemonThread()::$_0::operator()() const+268)
05-14 16:26:46.508 F/DEBUG   (  485):     #09 pc 000000000038287c  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (std::__ndk1::__invoke<realm::_impl::ExternalCommitHelper::DaemonThread::DaemonThread()::$_0>(decltype(std::__ndk1::forward<realm::_impl::ExternalCommitHelper::DaemonThread::DaemonThread()::$_0>(fp)(std::__ndk1::forward<>(fp0))), realm::_impl::ExternalCommitHelper::DaemonThread::DaemonThread()::$_0&&)+24)
05-14 16:26:46.508 F/DEBUG   (  485):     #10 pc 00000000003827dc  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so (_ZNSt6__ndk116__thread_executeINS_10unique_ptrINS_15__thread_structENS_14default_deleteIS2_EEEEZN5realm5_impl20ExternalCommitHelper12DaemonThreadC1EvE3$_0JEJEEEvRNS_5tupleIJT_T0_DpT1_EEENS_15__tuple_indicesIJXspT2_EEEE+32)
05-14 16:26:46.509 F/DEBUG   (  485):     #11 pc 000000000038218c  /data/app/io.realm.test-1/lib/arm64/librealm-jni.so

So the problem is not isolated to Core 10 it seems

This was triggered on our CI device, which is a Nexus 5

@RealmBot
Copy link
Collaborator

➤ Kenneth Geisshirt commented:

Same error message is observed when I try the following script using JS v10.0.0-alpha.5 (core v10.0.0-alpha.8; sync v10.0.0-alpha.12):

const Realm = require("realm");

let realm = new Realm({ path: "demo.realm" });
console.log(Schema:\n${JSON.stringify(realm.schema)}\n\n);

// Try adding a new class
if (realm.schema.length === 3) {
{{  realm.write(() => {}}
{{    realm._updateSchema([}}
{{      ...realm.schema,}}
{{      { name: "NewClass", properties: }}{ name: 'string' } },
{{    ]);}}
{{  });}}
}

realm.close();

The file can be downloaded as curl [https://static.realm.io/downloads/realm-studio/demo.realm] -O

@RealmBot
Copy link
Collaborator

➤ Kenneth Geisshirt commented:

I have performed a couple of small experiments. The minimal example to trigger the exception is:

  1. Generate a Realm file using JS v5.0.5 (based on core v5.23.8).
  2. Open the file using JS v10.0.0-alpha.5 (based on core v10.0.0-alpha.8). I installed without sync and verified at runtime sync was absent.
  3. Observe schema and objects are correct.
  4. Perform an empty transaction. The exception is thrown before the commit completes.

If I use JS v6.0.0 (based on core v6.0.4) in step 2, I don't observe the exception.

Another important observation is following:

  1. Generate a Realm file using JS v5.0.5 (based on core v5.23.8).
  2. Open the file using JS v10.0.0-alpha.5 (based on core v10.0.0-alpha.8).
  3. Observe schema and objects are correct.
  4. Create a new object in a transaction. The exception is thrown.
  5. Rerun the script
  6. The object created in step 4 is in file!

@finnschiermer
Copy link
Contributor Author

The fact that the commit goes through despite the error is just correct behavior. All file changes during commit are complete when the bug happens. It happens when references in table accessors are updated to reflect the movement of data in the file done as part of the commit.

@RealmBot
Copy link
Collaborator

➤ Finn Andersen commented:

Note: The report earlier about it being seen on Core-6 should be viewed with some reservation. There are many ways to hit a nosuchtable exception. Without the stack trace we cannot be confident it's the same bug

@cmelchior
Copy link
Contributor

Fair enough. The stacktrace I had directly in Core-6 was also different than the other ones we seen 👍

@finnschiermer
Copy link
Contributor Author

@cmelchior In your original bug report, is it possible that a realm database generated by Core-5 was present at the point where you ran your test (and thus a file format upgrade took place), while no such realm file was present at @nhachicha 's phone when he did it?

@cmelchior
Copy link
Contributor

@finnschiermer No, it ran from a clean state.

@finnschiermer
Copy link
Contributor Author

finnschiermer commented May 26, 2020 •
edited
Loading

Using OS + Core + JS, I can only reproduce the JS-variant of this bug with v10, not with v6, so it may be in v10 only (or the bug reported for JS may be different from the one reported for Java)

finnschiermer added a commit that referenced this issue May 27, 2020
@finnschiermer
experimental change to see effect on #3701
5e2dbda
@finnschiermer
Copy link
Contributor Author

Tentative fix in #3749.

@finnschiermer
Copy link
Contributor Author

The understanding of this bug is still insufficient. The tentative fix cannot explain why we observe different behavior on different phones.

@finnschiermer
Copy link
Contributor Author

Fix in progress #3749. The bug is in both v6 and v10.

@RealmBot
Copy link
Collaborator

RealmBot commented Jun 2, 2020

➤ Brian Munkholm commented:

While this seems fixed in JS we should confirm this also fixes related issues in Java.
Also working on reproduce this in a unit test.

@ironage
Copy link
Contributor

ironage commented Jun 4, 2020 •
edited
Loading

I think I have another instance of this bug in js using core/sync 10.0.0-beta.1 (it happened in CI I have not seen it locally)

Starting test testCreateMultipleEmbeddedObjects
uncaught exception in notifier thread: N5realm11NoSuchTableE: No such table exists
Exception backtrace:
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(_ZNK5realm13ConstTableRef5checkEv+0x78) [0x7fc38d854188]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(_ZNK5realm13ConstTableRefptEv+0x9) [0x7fc38d8541d9]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(_ZN5realm11Transaction14import_copy_ofENS_13ConstTableRefE+0x19) [0x7fc38d7bf869]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(_ZN5realm5QueryC2EPKS0_PNS_11TransactionENS_13PayloadPolicyE+0x170) [0x7fc38d65b0c0]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(_ZN5realm11Transaction14import_copy_ofERNS_5QueryENS_13PayloadPolicyE+0x32) [0x7fc38d7bfde2]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0x409db8) [0x7fc38d353db8]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0x3f0542) [0x7fc38d33a542]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0x404963) [0x7fc38d34e963]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0x405275) [0x7fc38d34f275]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0x41b16c) [0x7fc38d36516c]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0x41b210) [0x7fc38d365210]
/mnt/jenkins/workspace/realm_realm-js_PR-2901/compiled/node-v64_linux_x64/realm.node(+0xb91ce0) [0x7fc38dadbce0]
/lib64/libpthread.so.0(+0x7ea5) [0x7fc3909acea5]
/lib64/libc.so.6(clone+0x6d) [0x7fc3906d58dd]
terminate called after throwing an instance of 'realm::NoSuchTable'
  what():  No such table exists

The test is here:

testCreateMultipleEmbeddedObjects: function() {
        const realm = new Realm({schema: [schemas.HouseOwnerSchema, schemas.AddressSchema]});

        realm.write(() => {
            realm.create(schemas.HouseOwnerSchema.name, { name: "Ib", addresses: [
                { street: "Algade", city: "Nordby" },
                { street: "Skolevej", city: "Sydpynten" }
            ]});
            realm.create(schemas.HouseOwnerSchema.name, { name: "Petra", addresses: [
                { street: "Algade", city: "Nordby" }
            ]});
            realm.create(schemas.HouseOwnerSchema.name, { name: "Hans" });
        });

        let owners = realm.objects(schemas.HouseOwnerSchema.name).sorted("name");
        let addresses = realm.objects(schemas.AddressSchema.name).sorted("street");
        TestCase.assertEqual(owners.length, 3);
        TestCase.assertEqual(addresses.length, 3);

        const names = ["Hans", "Ib", "Petra"];
        for (let i = 0; i < names.length; i++) {
            TestCase.assertEqual(owners[i]["name"], names[i]);
        }

        let streets = ["Algade", "Algade", "Skolevej"];
        for (let i = 0; i < streets.length; i++) {
            TestCase.assertEqual(addresses[i]["street"], streets[i]);
        }

        realm.write(() => {
            addresses[0]["street"] = "Strandvejen";
        });

        streets = ["Algade", "Skolevej", "Strandvejen"];
        for (let i = 0; i < streets.length; i++) {
            TestCase.assertEqual(addresses[i]["street"], streets[i]);
        }

        realm.close();
    }

@finnschiermer finnschiermer mentioned this issue Jun 4, 2020
Closed
@finnschiermer
Copy link
Contributor Author

The last report is a different error, so putting it in a new issue #3761

@finnschiermer
Copy link
Contributor Author

Current analysis is that the bug reported for JS by @kneth has now been solved, but the original bug in the top of this issue, reported by @cmelchior may be different and not fixed yet.

@cmelchior
Copy link
Contributor

Using a release with the fix seems to make the bug go away on Android as well 👍

@cmelchior
Copy link
Contributor

I'll close this issue for now. If we get new sightings I'll reopen.

@cmelchior cmelchior mentioned this issue Jun 17, 2020
Closed
@RealmBot RealmBot mentioned this issue Jun 17, 2020
Closed
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
T-Bug-Crash
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@cmelchior @ironage @finnschiermer @RealmBot