New issue
Advanced search Search tips

Issue 630629 link

Starred by 2 users
Status: Fixed
Owner:
mark@chromium.org
Closed: Aug 2016
Cc:
jochen@chromium.org
machenb...@chromium.org
rsesek@chromium.org
mac-bugs-priority@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

Mac debug (non-component) build fails verify_order step due to exported v8 symbols

Project Member Reported by mark@chromium.org, Jul 22 2016 
At the tip of master (or close to it, I’m at 8dff50bad755):

[17397/17406] ACTION //chrome:verify_c...order(//build/toolchain/mac:clang_x64)
FAILED: obj/chrome/run_verify_chrome_framework_order.stamp 
python ../../chrome/tools/build/mac/run_verify_order.py --stamp obj/chrome/run_verify_chrome_framework_order.stamp _ChromeMain Chromium\ Framework.framework/Chromium\ Framework
../../chrome/tools/build/mac/verify_order: unordered symbols in Chromium Framework.framework/Chromium Framework:
__ZN2v88internal9Accessors12MakeAccessorEPNS0_7IsolateENS0_6HandleINS0_4NameEEEPFvNS_5LocalINS_4NameEEERKNS_20PropertyCallbackInfoINS_5ValueEEEEPFvS9_NS7_ISB_EERKNSA_IvEEENS0_18PropertyAttributesE
[…and lots of other v8 symbols…]

The full output is attached.

This was caused by v8 0ae0fbce8be4 (https://codereview.chromium.org/2168593002), which rolled into Chrome at c7cba53d2f8c (https://codereview.chromium.org/2164963002), but probably didn’t have any effect in Chrome until d65ec5c9df40 (https://codereview.chromium.org/2058033002,  bug 616034 )

Oddly, it seems that we don’t have any bots currently monitoring this most basic and default of all configurations.
verify_order.txt
10.1 KB View Download

Comment 2 by mark@chromium.org, Jul 22 2016 

 Bug 630634  for “why didn’t the bots catch this?”

Comment 3 by mark@chromium.org, Jul 22 2016 

Alternative at Jochen’s request: https://codereview.chromium.org/2171373002 (reverts v8 313886270307, https://codereview.chromium.org/2167723004)

Comment 4 by mark@chromium.org, Jul 22 2016

Owner: mark@chromium.org
Status: Started (was: Untriaged)
Project Member

Comment 5 by bugdroid1@chromium.org, Jul 22 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/7883414e8b4d1646423b9a1a645a7a4ddb077c38

commit 7883414e8b4d1646423b9a1a645a7a4ddb077c38
Author: mark <mark@chromium.org>
Date: Fri Jul 22 18:13:08 2016

Revert "Enable v8 backtrace support in all debug builds"

This reverts commit 3138862703079c60dcc2406dca1011fcacb4e264.

BUG= chromium:630629 

Review-Url: https://codereview.chromium.org/2171373002
Cr-Commit-Position: refs/heads/master@{#37986}

[modify] https://crrev.com/7883414e8b4d1646423b9a1a645a7a4ddb077c38/gni/v8.gni

Comment 6 by jochen@chromium.org, Jul 27 2016 

Can you explain what this step does?

In v8, we use dladdr() to symbolize stack traces, and that only works when we link with -rdynamic: https://cs.chromium.org/chromium/src/v8/src/base/logging.cc?rcl=0&l=66

looking at the code, I wonder whether those #ifdefs are true on mac at all...

Comment 7 by rsesek@chromium.org, Jul 27 2016 

The step makes sure there are no global text symbols at an address higher than _ChromeMain (as specified in the .order file).

I think the original intent was so that in stack traces that are symbolized on stripped builds, _ChromeMain is the symbol that is used for all the frames, rather than some other arbitrary one.

Comment 8 by mark@chromium.org, Aug 2 2016

Status: Fixed (was: Started)
►

Sign in to add a comment