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

[Android] Encrypted realms crash when combined with CookieManager (OpenSSL) #757

Closed
cmelchior opened this issue Apr 9, 2015 · 6 comments
Closed

[Android] Encrypted realms crash when combined with CookieManager (OpenSSL) #757

cmelchior opened this issue Apr 9, 2015 · 6 comments
Labels
T-Bug

Comments

@cmelchior
Copy link
Contributor

Hi

We are seeing a really weird crash on Android when combining encrypted realms with the CookieManager on Android.

A user has been able to make a reproducible case, and I have so far failed to reproduce it outside a Android setting. Branch is here: https://github.com/realm/realm-java/tree/cm-bug-crash-cookiemanager

Our findings so far is here: https://github.com/realm/realm-java/blob/cm-bug-crash-cookiemanager/experimental/cookieManager/debugging.txt

Current thesis is that CookieManager uses the Chromium CookieManager shipped with Android 5+ which calls some native code that uses OpenSSL and that somehow conflicts with our usage of OpenSSL, but really we have no idea.

I assume @tgoyne is the goto guy on this?

Issue is also tracked on the realm-java here: realm/realm-java#1008
@cmelchior cmelchior added the T-Bug label Apr 9, 2015
@cmelchior
Copy link
Contributor Author

Another user is reporting the same error but apparently in a slightly different context that sounds like it is easier to reproduce. I'll try to get a reproducible test case from him: realm/realm-java#1023

@cmelchior
Copy link
Contributor Author

A user provided a much simpler test case that is single threaded:

  1. Create a webview
  2. Start a transaction
  3. Calling commit then crashes core.

Project is here: https://github.com/realm/realm-java/tree/cm-bug-crash-cookiemanager/experimental/webviewCrash

@tgoyne
Copy link
Member

tgoyne commented Apr 14, 2015

Some more detailed logs, starting from the realm.commitTransaction():

with webview:

04-13 17:42:51.630 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a84007c
04-13 17:42:51.630 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:42:51.630 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:42:51.631 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:42:51.634 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:42:51.649 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a840017
04-13 17:42:51.649 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:42:51.649 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:42:51.649 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:42:51.649 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:42:51.688 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:42:51.688 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:42:51.689 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a83528c
04-13 17:42:51.689 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ reading page
04-13 17:42:51.689 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ opening active log
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ remapping log
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ remapping log done
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ writing size to 0x5a83a000 (0x5a83a000 + 0)
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x78ca
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ unhandled signal
04-13 17:43:18.908 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ calling old sa_sigaction
04-13 17:43:18.959 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ old sa_sigaction done
04-13 17:43:18.960 30922-30922/io.realm.webviewcrash E/TIGHTDB﹕ signal handler fell through

04-13 17:43:19.017 123-123/? I/DEBUG﹕ *** *** *** *** *** *** *** *** *** *** *** *** *** *** ** ***
04-13 17:43:19.020 123-123/? I/DEBUG﹕ Build fingerprint: 'google/nakasi/grouper:5.1/LMY47D/1743759:user/release-keys'
04-13 17:43:19.021 123-123/? I/DEBUG﹕ Revision: '0'
04-13 17:43:19.022 123-123/? I/DEBUG﹕ ABI: 'arm'
04-13 17:43:19.024 123-123/? I/DEBUG﹕ pid: 30922, tid: 30922, name: lm.webviewcrash >>> io.realm.webviewcrash <<<
04-13 17:43:19.025 123-123/? I/DEBUG﹕ signal 11 (SIGSEGV), code -6 (SI_TKILL), fault addr 0x5a83a000
04-13 17:43:19.080 123-123/? I/DEBUG﹕ r0 00000035 r1 5a83a000 r2 00000b6d r3 00000000
04-13 17:43:19.084 123-123/? I/DEBUG﹕ r4 6a41f65d r5 12d0ef40 r6 5a831008 r7 beff3a60
04-13 17:43:19.089 123-123/? I/DEBUG﹕ r8 7474b438 r9 400b05b0 sl 12d08ec0 fp 00e3d1b0
04-13 17:43:19.091 123-123/? I/DEBUG﹕ ip beff3590 sp beff3a50 lr 6a41ecff pc 6a41ed04 cpsr 600f0030
04-13 17:43:19.091 123-123/? I/DEBUG﹕ backtrace:
04-13 17:43:19.093 123-123/? I/DEBUG﹕ #00 pc 00122d04 /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (tightdb::_impl::WriteLogCollector::internal_submit_log(char const, unsigned long long)+339)
04-13 17:43:19.094 123-123/? I/DEBUG﹕ #1 pc 0012369b /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (tightdb::_impl::WriteLogCollector::do_commit_write_transact(tightdb::SharedGroup&, unsigned long long)+62)
04-13 17:43:19.095 123-123/? I/DEBUG﹕ #2 pc 00137d9b /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (tightdb::Replication::commit_write_transact(tightdb::SharedGroup&, unsigned long long)+30)
04-13 17:43:19.095 123-123/? I/DEBUG﹕ #3 pc 00137165 /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (tightdb::SharedGroup::do_commit()+156)
04-13 17:43:19.095 123-123/? I/DEBUG﹕ #4 pc 00136fbf /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (tightdb::SharedGroup::commit_and_continue_as_read()+10)
04-13 17:43:19.095 123-123/? I/DEBUG﹕ #5 pc 00032eb3 /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (tightdb::LangBindHelper::commit_and_continue_as_read(tightdb::SharedGroup&)+10)
04-13 17:43:19.095 123-123/? I/DEBUG﹕ #6 pc 00033b97 /data/app/io.realm.webviewcrash-1/lib/arm/libtightdb-jni.so (Java_io_realm_internal_SharedGroup_nativeCommitAndContinueAsRead+62)
04-13 17:43:19.095 123-123/? I/DEBUG﹕ #7 pc 000bac5f /data/dalvik-cache/arm/data@app@io.realm.webviewcrash-1@base.apk@classes.dex

without webview:

04-13 17:46:10.215 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a84007c
04-13 17:46:10.216 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:10.216 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:10.216 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:10.217 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:10.230 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a840017
04-13 17:46:10.230 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:10.230 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:10.230 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:10.230 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:10.244 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:10.245 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:10.245 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a83528c
04-13 17:46:10.245 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ reading page
04-13 17:46:10.245 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.286 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ opening active log
04-13 17:46:33.286 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ remapping log
04-13 17:46:33.286 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ remapping log done
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ writing size to 0x5a83a000 (0x5a83a000 + 0)
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a83a000
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ appending log data
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ syncing log
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.287 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.301 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ updating preamble
04-13 17:46:33.301 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ syncing header
04-13 17:46:33.301 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ internal_submit_log done
04-13 17:46:33.301 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.301 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.302 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a853434
04-13 17:46:33.302 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:33.302 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.302 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a854cdc
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ reading page
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a854cdc
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:33.303 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a835284
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ reading page
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a854f8c
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.304 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.321 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a854017
04-13 17:46:33.321 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ making page writable
04-13 17:46:33.321 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.321 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.322 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.336 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.336 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.337 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ flushing
04-13 17:46:33.337 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done
04-13 17:46:33.337 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ signal: 0x5a853fb4
04-13 17:46:33.337 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ reading page
04-13 17:46:33.338 31857-31857/io.realm.webviewcrash E/TIGHTDB﹕ done

The interesting difference starts at "writing size to 0x5a83a000 (0x5a83a000 + 0)" -- with a WebView created, the signal immediately after that gets a blatantly incorrect memory address, while without the WebView it gets the correct memory address. This suggests that the webview is installing a broken signal handler (on a different thread, and the earlier things just happen to work because they run before it?).

@cmelchior
Copy link
Contributor Author

I have created an issue on the Chromium issue tracker with this: https://code.google.com/p/chromium/issues/detail?id=476831

But if there is anything we can do on our end to fix this problem it is probably worth doing.

@tgoyne
Copy link
Member

tgoyne commented Apr 14, 2015

I uploaded a minimal repro case that doesn't use Realm at all to the chromium ticket. I'm not sure what we could do to work around this other than reinstalling the signal handler constantly in the hopes of staying the first one when it matters (or reworking everything to not need signals, which I'm increasingly thinking would be worth doing, but definitely wouldn't be a quick fix).

@kneth kneth mentioned this issue Apr 15, 2015
Closed
@finnschiermer
Copy link
Contributor

I'm opening a task on doing encryption without use of signals, and closing this one.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 22, 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
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cmelchior @tgoyne @finnschiermer