[GN] snapshot_blob.bin is not generated correctly for Cast |
||||||
Issue descriptionHey all, We ran into a weird issue last week where certain web apps fail without much warning on Chromecast for GN builds. The problems do not occur on the GYP build. Through a few hours of debugging, I've discovered that snapshot_blob.bin seems to be the culprit; copying a GYP-built snapshot_blob.bin onto a GN build solves the issue. It looks like mksnapshot is invoked with different args between GN and GYP: GN: python ../../v8/tools/run.py ./x86_clang/mksnapshot --log-snapshot-positions --logfile gen/v8/snapshot.log --startup_src gen/v8/snapshot.cc --random-seed 314159265 --startup_blob snapshot_blob.bin GYP: cd ../../v8/tools/gyp; ../../../out_arm_chromecast_salami/Release/mksnapshot --log-snapshot-positions --logfile ../../../out_arm_chromecast_salami/Release/obj/v8/tools/gyp/v8_external_snapshot.gen/snapshot.log --random-seed 314159265 --startup_blob ../../../out_arm_chromecast_salami/Release/snapshot_blob.bin "" But even when the args are modified locally, the resulting snapshot_blob.bin is still no good. I suspect that this has to do with the way that mksnapshot is built. One more data point, the GN and GYP builds differ in size by 8 bytes. This struck me as very odd. A few questions: 1) Right now, mksnapshot is hardcoded to build with the host clang toolchain. Our target toolchain uses gcc, and our GYP build compiles mksnapshot with the host gcc toolchain. I changed the mksnapshot toolchain to use gcc as well, but this didn't change anything (I didn't expect it to). Can we write this off as a possible cause? 2) Do we have a way to test whether the snapshot_blob.bin binary is valid? And if not, what might be wrong? 3) Where should I look to start logging stuff in Chrome about _why_ snapshot_blob.bin is failing? v8/src/api.cc looks promising, but my first pass at printf debugging was fruitless :) I will continue deep-diving, but any helpful pointer would be appreciated! Thanks!
,
Mar 7 2016
Unfortunately, we see no logs indicating failure. The symptoms of failure are fairly specific to chromecast - Certain JS applications will fail to load, then will generally kill themselves, sensing a problem. This does not happen to every app, and I'm not quite what is common among problematic apps. If specifics about the apps would be helpful, I can provide you with more information on an internal channel. I added some logging to startup-data-util.cc to attempt to reveal loading errors, but it has not been helpful so far.
,
Mar 7 2016
Nevermind - i see that this is a bad place to add logging: startup-data-util.h // This is meant as a convenience for stand-alone binaries like d8, cctest, // unittest. I'll look elsewhere.
,
Mar 8 2016
can you provide repro steps? given that android gn appears to work, I suspect that there's some setup issue in your gn configuration
,
Mar 8 2016
note that the snapshot also has some basic checksums built in, so if it was completely off, it would just not load at all.
,
Mar 28 2016
,
Mar 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0 commit d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0 Author: slan <slan@chromium.org> Date: Wed Mar 30 01:20:43 2016 [GN] Declare arm arguments when target_cpu == "arm". These variables should be declared when target_cpu is "arm", so that cross-compiles may use these arguments to determine how to build host tools. Related change in //v8: https://codereview.chromium.org/1839763003/ BUG= 592660 Review URL: https://codereview.chromium.org/1842833003 Cr-Commit-Position: refs/heads/master@{#383888} [modify] https://crrev.com/d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0/build/config/arm.gni
,
Mar 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0 commit d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0 Author: slan <slan@chromium.org> Date: Wed Mar 30 01:20:43 2016 [GN] Declare arm arguments when target_cpu == "arm". These variables should be declared when target_cpu is "arm", so that cross-compiles may use these arguments to determine how to build host tools. Related change in //v8: https://codereview.chromium.org/1839763003/ BUG= 592660 Review URL: https://codereview.chromium.org/1842833003 Cr-Commit-Position: refs/heads/master@{#383888} [modify] https://crrev.com/d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0/build/config/arm.gni
,
Apr 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9ad45bcd53fd0fe40c962ebff8dd7bc3b2d289c9 commit 9ad45bcd53fd0fe40c962ebff8dd7bc3b2d289c9 Author: mcgrathr <mcgrathr@chromium.org> Date: Fri Apr 01 22:09:38 2016 GN: Declare ARM build arguments for either target_cpu or current_cpu == "arm" The change in crrev.com/d2eec2ae67e1494bb3a9aa7e0f1c1612298cccc0 fixed crbug.com/592660 but caused crbug.com/599896 . The ARM build arguments are relevant both in a build where target_cpu=="arm" and, in other builds, in toolchain contexts where current_cpu=="arm". For example, NaCl toolchains for all different current_cpu values might be instantiated in a build where target_cpu ist something else. BUG= 592660 BUG= 599896 CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_dbg_32_ng,linux_nacl_sdk_build R=dpranke@chromium.org Review URL: https://codereview.chromium.org/1847063006 Cr-Commit-Position: refs/heads/master@{#384703} [modify] https://crrev.com/9ad45bcd53fd0fe40c962ebff8dd7bc3b2d289c9/build/config/arm.gni
,
Apr 1 2016
Thanks for the cleanup, Roland. I'm going to close out this bug, as the original problem is solved.
,
May 5 2016
Unfortunately, the fixing change was reverted due to some bad behavior on ARM android builds: https://codereview.chromium.org/1839763003/ Opening this back up for further investigation in the near future.
,
Oct 20 2016
We haven't seen this issue in a while. Going to close it out as obsolete. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by jochen@chromium.org
, Mar 7 2016