Signing into facebook leading to v8 crash on ToT |
||||||||||||||||||||
Issue descriptionI'm synced to 1b1572b4493d59e4af008b1351137297f6fb42c5 1. build chrome_public_apk and install it. 2. open facebook and sign in 3. crash in V8?! With a pile of SELinux violations before it: 05-13 17:36:43.816 23890 23911 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 23911 (CrRendererMain) 05-13 17:36:43.919 22192 22192 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 05-13 17:36:43.919 22192 22192 F DEBUG : Build fingerprint: 'google/hammerhead/hammerhead:6.0.1/MMB29V/2554798:userdebug/dev-keys' 05-13 17:36:43.919 22192 22192 F DEBUG : Revision: '0' 05-13 17:36:43.919 22192 22192 F DEBUG : ABI: 'arm' 05-13 17:36:43.921 22192 22192 F DEBUG : pid: 23890, tid: 23911, name: CrRendererMain >>> org.chromium.chrome:sandboxed_process1 <<< 05-13 17:36:43.921 22192 22192 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x8 05-13 17:36:43.916 22192 22192 W debuggerd: type=1400 audit(0.0:3073): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.916 22192 22192 W debuggerd: type=1400 audit(0.0:3074): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3075): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3076): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3077): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3078): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3079): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3080): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3081): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3082): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3083): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3084): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3085): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3086): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3087): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3088): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3089): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3090): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3091): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.926 22192 22192 W debuggerd: type=1400 audit(0.0:3092): avc: denied { search } for name="org.chromium.chrome" dev="mmcblk0p28" ino=89602 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_da ta_file:s0:c512,c768 tclass=dir permissive=0 05-13 17:36:43.983 22192 22192 F DEBUG : r0 00000000 r1 f8cdbe2d r2 00000000 r3 00000ffb 05-13 17:36:43.983 22192 22192 F DEBUG : r4 00000001 r5 9f9bb32d r6 20d087e1 r7 96d2b079 05-13 17:36:43.983 22192 22192 F DEBUG : r8 00000000 r9 20d082b9 sl 99512024 fp a0abcc44 05-13 17:36:43.983 22192 22192 F DEBUG : ip 9fc30fe0 sp a0abcc20 lr 9f58fa9f pc 26f385cc cpsr 680b0010 05-13 17:36:43.984 22192 22192 F DEBUG : 05-13 17:36:43.984 22192 22192 F DEBUG : backtrace: 05-13 17:36:43.985 22192 22192 F DEBUG : #00 pc 0002e5cc <unknown> 05-13 17:36:43.985 22192 22192 F DEBUG : #01 pc 00050a9b /data/data/org.chromium.chrome/incremental-install-files/lib/libv8.cr.so 05-13 17:36:43.985 22192 22192 F DEBUG : #02 pc 00074ba3 <unknown> 05-13 17:36:44.831 22192 22192 F DEBUG : 05-13 17:36:44.831 22192 22192 F DEBUG : Tombstone written to: /data/tombstones/tombstone_03 05-13 17:36:44.831 22192 22192 E DEBUG : AM write failed: Broken pipe I also see some graphics-related hints from the GPU process (which doesn't crash) like: 05-13 17:51:12.780 26210 26235 E libEGL : validate_display:255 error 3008 (EGL_BAD_DISPLAY) 05-13 17:51:12.780 26210 26235 I Adreno-EGL: <qeglDrvAPI_eglInitialize:379>: QUALCOMM Build: 10/21/15, 369a2ea, I96aee987eb 05-13 17:51:12.855 26210 26235 W VideoCapabilities: Unrecognized profile 2130706433 for video/avc 05-13 17:51:12.879 26210 26235 I VideoCapabilities: Unsupported profile 4 for video/mp4v-es aelias: does that goop mean anything to you?
,
May 13 2016
I love the backtrace haha 0: unknown 1: anywhere in V8 2: unknown
,
May 16 2016
Is build/android/tombstones.py able to pull anything out of the tombstone?
,
May 16 2016
It does typical symbolization but same result as above
,
May 16 2016
I've confirmed that the SELinux policy violations are a red herring. Turning on permissive mode still results in the same crash
,
May 16 2016
Tried building non-component build it's still broken.
,
May 16 2016
I suspect the crash is from some v8 roll and we'll need to bisect it to narrow it down
,
May 16 2016
This still reproes on r393932 local ChromePublic build for me. For some reason, it doesn't affect our cloudstorage prebuilts in the same way though -- the content area goes black on facebook instead on 52.0.2738.0, without showing a sad tab, which I'm guessing might be a different manifestation of the same bug. Anyway, I've started to bisect.
,
May 17 2016
Bisected to V8 roll r391471, V8 range https://chromium.googlesource.com/v8/v8/+log/b6bedb6f..67a85523, bisected within that to https://codereview.chromium.org/1946883003 "Ship Turbofan optimization for try-catch and try-finally."
,
May 17 2016
jarin@, ping; M52 release branch cut is this week, so can we revert? Seems to just be a feature bit flip change.
,
May 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/cab4685e3515a69de8d920d1a2c5a531c87fc3d7 commit cab4685e3515a69de8d920d1a2c5a531c87fc3d7 Author: hablich <hablich@chromium.org> Date: Wed May 18 07:48:45 2016 Revert of Ship Turbofan optimization for try-catch and try-finally. (patchset #1 id:1 of https://codereview.chromium.org/1946883003/ ) Reason for revert: Reverted because of BUG= chromium:611885 Original issue's description: > Ship Turbofan optimization for try-catch and try-finally. > > Committed: https://crrev.com/b84b01e6d2d8a0ed1e6b9186a5af755bab4bac9a > Cr-Commit-Position: refs/heads/master@{#36005} TBR=bmeurer@chromium.org,jarin@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. Review-Url: https://codereview.chromium.org/1994543002 Cr-Commit-Position: refs/heads/master@{#36309} [modify] https://crrev.com/cab4685e3515a69de8d920d1a2c5a531c87fc3d7/src/ast/ast-numbering.cc
,
May 18 2016
This is reverted for now. aelias@ can you please provide detailed repro steps so we can fix the bug?
,
May 18 2016
I managed to repro on my phone just now, so the steps are not really necessary. Thanks for the report.
,
May 18 2016
Did the revert roll into Chrome yet? I'm wondering if this perf waterfall crash is related: https://build.chromium.org/p/chromium.perf/builders/Win%207%20Intel%20GPU%20Perf%20%283%29/builds/3004/steps/tracing.tracing_with_debug_overhead/logs/stdio/text
,
May 18 2016
No, rolling right now: https://codereview.chromium.org/1995503002/
,
May 20 2016
This is reverted on on M52.
,
May 20 2016
,
May 20 2016
Simple repro is below, only reproduces on chrome on android-arm. It looks like the main culprit is the calling convention mix-up for returning C struct: we are assuming (in CEntryStub) that a function returns in r0 a pointer to the struct being returned, but on Chrome we get 0 in r0. Somehow, in d8 this works just fine, so there must be some subtle difference in calling conventions.
The problematic function is the Runtime_ForInPrepare function, which needs to return three values, and it uses a struct for that. Perhaps we should pass a pointer to the struct rather relying on ABI to do the right thing.
<script>
function f(a) {
with({}) {} // This makes sure that Turbofan kicks in.
for (var x in a) { }
}
for (var i = 0; i < 100000; i++) {
f([1]);
}
</script>
,
May 20 2016
> The problematic function is the Runtime_ForInPrepare function, which needs to > return three values, and it uses a struct for that. Perhaps we should pass a > pointer to the struct rather relying on ABI to do the right thing. We do already pass a pointer into the location on the stack which the return value should be placed. I think the solution is just to update the CEntryStub to read the result value from an offset of sp rather than what it currently does reading it from r0 (e.g., do the same as x64 does).
,
May 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/ca266e74cdbb53d2dc8a2103f877014888185c7f commit ca266e74cdbb53d2dc8a2103f877014888185c7f Author: jarin <jarin@chromium.org> Date: Fri May 20 14:36:54 2016 [arm] Make CEntryStub's handling of triple return values more robust. At the moment the code assumes C-function returns the address of the struct with the values. Unfortunately, the arm ABI does not guarantee that. After this CL, we do not assume that, and instead just take the value from the stack. BUG= chromium:611885 LOG=n Review-Url: https://codereview.chromium.org/2000713002 Cr-Commit-Position: refs/heads/master@{#36415} [modify] https://crrev.com/ca266e74cdbb53d2dc8a2103f877014888185c7f/src/arm/code-stubs-arm.cc
,
May 20 2016
,
May 23 2016
,
May 23 2016
[Automated comment] Less than 2 weeks to go before stable on M51, manual review required.
,
May 23 2016
Your change meets the bar and is auto-approved for M52 (branch: 2743)
,
May 23 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/4caf8366d0c949524f2acebde3419935dc6c4e28 commit 4caf8366d0c949524f2acebde3419935dc6c4e28 Author: Jaroslav Sevcik <jarin@chromium.org> Date: Mon May 23 14:05:06 2016 Version 5.2.361.5 (cherry-pick) Merged ca266e74cdbb53d2dc8a2103f877014888185c7f [arm] Make CEntryStub's handling of triple return values more robust. BUG= chromium:611885 LOG=N R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/2004013002 . Cr-Commit-Position: refs/branch-heads/5.2@{#7} Cr-Branched-From: 2cd36d6d0439ddfbe84cd90e112dced85084ec95-refs/heads/5.2.361@{#1} Cr-Branched-From: 3fef34e02388e07d46067c516320f1ff12304c8e-refs/heads/master@{#36332} [modify] https://crrev.com/4caf8366d0c949524f2acebde3419935dc6c4e28/include/v8-version.h [modify] https://crrev.com/4caf8366d0c949524f2acebde3419935dc6c4e28/src/arm/code-stubs-arm.cc
,
May 23 2016
,
May 23 2016
Assuming this is super low risk, merge approved for M51 branch 2704. Ping me if it's not super low risk but you still want it merged.
,
May 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/d18f1798ccab2264b669a25ba845cc92d5103e67 commit d18f1798ccab2264b669a25ba845cc92d5103e67 Author: Jaroslav Sevcik <jarin@chromium.org> Date: Wed May 25 04:32:48 2016 Version 5.1.281.48 (cherry-pick) Merged ca266e74cdbb53d2dc8a2103f877014888185c7f [arm] Make CEntryStub's handling of triple return values more robust. BUG= chromium:611885 LOG=N R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/2010633003 . Cr-Commit-Position: refs/branch-heads/5.1@{#58} Cr-Branched-From: 167dc63b4c9a1d0f0fe1b19af93644ac9a561e83-refs/heads/5.1.281@{#1} Cr-Branched-From: 03953f52bd4a184983a551927c406be6489ef89b-refs/heads/master@{#35282} [modify] https://crrev.com/d18f1798ccab2264b669a25ba845cc92d5103e67/include/v8-version.h [modify] https://crrev.com/d18f1798ccab2264b669a25ba845cc92d5103e67/src/arm/code-stubs-arm.cc
,
May 26 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 27 2016
,
Aug 15 2016
May also need to be floated on Node.js 6.x (for V8 5.0), but let us wait for closure on https://github.com/nodejs/node/pull/8054
,
Sep 1 2016
Node 6 has upgraded to V8 5.1, so a backport/float for 5.0 is no longer needed.
,
Sep 28 2016
|
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by aelias@chromium.org
, May 13 2016