New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 716395 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug

Blocking:
issue 713137



Sign in to add a comment

Sometimes CanvasRenderingContext's vtbl can be missing if combining Mac+Jumbo

Project Member Reported by brat...@opera.com, Apr 28 2017

Issue description

While testing jumbo (  https://crbug.com/713137  )in various configurations pdr encountered a non-obvious error in mac+goma. CanvasRendering's vtbl could not be found by the linker. It should have accompanied the DidDraw method, and the DidDraw method was present but the vtbl was not.

To reproduce:
1. Apply https://codereview.chromium.org/2821333003/
2. Make sure CanvasRenderingContext.cpp is not in jumbo_excluded_sources in third_party/WebKit/Source/core/html/BUILD.gn
3. Start a mac goma build of chrome.

Expected:
A chrome binary

Actual:
[21052/23929] SOLINK libblink_modules.dylib libblink_modules.dylib.TOC
FAILED: libblink_modules.dylib libblink_modules.dylib.TOC
export DEVELOPER_DIR=/Users/pdr/Desktop/chromium/src/build/mac_files/Xcode.app; if [ ! -e "./libblink_modules.dylib" -o ! -e "./libblink_modules.dylib.TOC" ] || otool -l "./libblink_modules.dylib" | grep -q LC_REEXPORT_DYLIB ; then TOOL_VERSION=1479524834 ../../build/toolchain/mac/linker_driver.py ../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared -Wl,-install_name,@rpath/"libblink_modules.dylib" -stdlib=libc++ -arch x86_64 -Werror -isysroot /Users/pdr/Desktop/chromium/src/build/mac_files/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.9 -Wl,-ObjC -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../.. -o "./libblink_modules.dylib" -Wl,-filelist,"./libblink_modules.dylib.rsp" ./libblink_core.dylib ./libbase.dylib ./libbindings.dylib ./libmojo_public_system_cpp.dylib ./libmojo_public_system.dylib ./libwtf.dylib ./libicui18n.dylib ./libicuuc.dylib ./libgles2_c_lib.dylib ./libskia.dylib ./libv8.dylib ./libchromium_sqlite3.dylib ./libgeometry.dylib ./liburl.dylib ./libblink_platform.dylib ./libcc.dylib ./libcc_base.dylib ./libcc_animation.dylib ./libcc_paint.dylib ./libcc_debug.dylib ./libcolor_space.dylib ./libgeometry_skia.dylib ./libgpu.dylib ./libgles2_utils.dylib ./libgfx.dylib ./libanimation.dylib ./libcodec.dylib ./librange.dylib ./libgl_wrapper.dylib ./libplatform.dylib ./libgl_init.dylib ./libipc.dylib ./libui_base.dylib ./libui_data_pack.dylib ./libevents_base.dylib ./libdisplay.dylib ./libdisplay_types.dylib ./libmedia.dylib ./libshared_memory_support.dylib ./libnet.dylib ./libprotobuf_lite.dylib ./libcrcrypto.dylib ./libboringssl.dylib ./libgin.dylib ./libbase_i18n.dylib ./libcpp.dylib ./libmojo_common_lib.dylib && { otool -l "./libblink_modules.dylib" | grep LC_ID_DYLIB -A 5; nm -gP "./libblink_modules.dylib" | cut -f1-2 -d' ' | grep -v U$$; true; } > "./libblink_modules.dylib.TOC"; else TOOL_VERSION=1479524834 ../../build/toolchain/mac/linker_driver.py ../../third_party/llvm-build/Release+Asserts/bin/clang++ -shared -Wl,-install_name,@rpath/"libblink_modules.dylib" -stdlib=libc++ -arch x86_64 -Werror -isysroot /Users/pdr/Desktop/chromium/src/build/mac_files/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.9 -Wl,-ObjC -Wl,-rpath,@loader_path/. -Wl,-rpath,@loader_path/../../.. -o "./libblink_modules.dylib" -Wl,-filelist,"./libblink_modules.dylib.rsp" ./libblink_core.dylib ./libbase.dylib ./libbindings.dylib ./libmojo_public_system_cpp.dylib ./libmojo_public_system.dylib ./libwtf.dylib ./libicui18n.dylib ./libicuuc.dylib ./libgles2_c_lib.dylib./libskia.dylib ./libv8.dylib ./libchromium_sqlite3.dylib ./libgeometry.dylib ./liburl.dylib ./libblink_platform.dylib ./libcc.dylib ./libcc_base.dylib ./libcc_animation.dylib ./libcc_paint.dylib ./libcc_debug.dylib ./libcolor_space.dylib ./libgeometry_skia.dylib ./libgpu.dylib ./libgles2_utils.dylib ./libgfx.dylib ./libanimation.dylib ./libcodec.dylib ./librange.dylib ./libgl_wrapper.dylib ./libplatform.dylib ./libgl_init.dylib ./libipc.dylib ./libui_base.dylib ./libui_data_pack.dylib ./libevents_base.dylib ./libdisplay.dylib ./libdisplay_types.dylib ./libmedia.dylib ./libshared_memory_support.dylib ./libnet.dylib ./libprotobuf_lite.dylib ./libcrcrypto.dylib ./libboringssl.dylib ./libgin.dylib ./libbase_i18n.dylib ./libcpp.dylib ./libmojo_common_lib.dylib && { otool -l "./libblink_modules.dylib" | grep LC_ID_DYLIB -A 5; nm -gP "./libblink_modules.dylib" | cut -f1-2 -d' ' | grep -v U$$; true; } > "./libblink_modules.dylib.tmp" && if ! cmp -s "./libblink_modules.dylib.tmp" "./libblink_modules.dylib.TOC"; then mv "./libblink_modules.dylib.tmp" "./libblink_modules.dylib.TOC" ; fi; fi
Undefined symbols for architecture x86_64:
 "vtable for blink::CanvasRenderingContext", referenced from:
 blink::CanvasRenderingContext::~CanvasRenderingContext() in CanvasRenderingContext2D.o
 blink::CanvasRenderingContext::~CanvasRenderingContext() in ImageBitmapRenderingContext.o
 blink::CanvasRenderingContext::~CanvasRenderingContext() in OffscreenCanvasRenderingContext2D.o
 blink::CanvasRenderingContext::~CanvasRenderingContext() in WebGLRenderingContextBase.o
 NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
ninja: build stopped: subcommand failed.

Workarounds:
1. Inserting a dummy non-inline virtual function early in the CanvasRenderingContext class definition made the vtbl appear.
2. Excluding CanvasRenderingContext.cpp from jumbo should work.

Short term I will add CanvasRenderingContext.cpp to the exclusion list (bah!) but this might be a problem with the compiler. It will get a lot more data to work on with jumbo so the chances of getting confused is larger.
 

Comment 1 by brat...@opera.com, Jul 4 2017

Cc: y...@yoav.ws
yoav seems to have encountered the same thing in the Modulator class, another class that also inherits the GC mixin so that seems to be relevant in some way.

Comment 2 by y...@yoav.ws, Jul 4 2017

Yeah, the error I'm getting is:
```
Undefined symbols for architecture x86_64:
  "vtable for blink::Modulator", referenced from:
      blink::DummyModulator::DummyModulator() in DummyModulator.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
Project Member

Comment 3 by bugdroid1@chromium.org, Jul 4 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f32493d6645c569588e18d400ab1ef62135618d9

commit f32493d6645c569588e18d400ab1ef62135618d9
Author: Yoav Weiss <yoav@yoav.ws>
Date: Tue Jul 04 15:34:02 2017

Exclude Modular.cpp from jumbo build

The Jumbo build fails to link classes derived from Modular, so we're
excluding it from the jumbo build until we figure it out.

Bug: 716395
Change-Id: I39b128294829cd7d4fc94b03135a775111444b6a
Reviewed-on: https://chromium-review.googlesource.com/559053
Commit-Queue: Yoav Weiss <yoav@yoav.ws>
Reviewed-by: bratell at Opera <bratell@opera.com>
Cr-Commit-Position: refs/heads/master@{#484109}
[modify] https://crrev.com/f32493d6645c569588e18d400ab1ef62135618d9/third_party/WebKit/Source/core/dom/BUILD.gn

Comment 4 by brat...@opera.com, Jul 5 2017

Summary: Sometimes CanvasRenderingContext's vtbl can be missing if combining Mac+Jumbo (was: Sometimes CanvasRenderingContext's vtbl can be missing if combining Mac+Jumbo+goma)
Since it happened to yoav, I'm dropping the "goma" part of the problem description. One less factor to worry about.

Comment 5 by brat...@opera.com, Jul 18 2017

Blocking: 713137
Labels: OS-Mac
Status: Available (was: Untriaged)
yoav encountered it again, and again with a class with USING_GARBAGE_COLLECTED_MIXIN. This time ScriptPromiseResolver. There is something with the USING_GARBAGE_COLLECTED_MIXIN, and Mac, and non-bot compilations that trigger this. 

I don't have a mac to try to debug on, but it should be something like this:

The vtbl follows the first non-inline virtual function in a class. Could it be that the compiler gets confused regarding what function is actually the first non-inline virtual function?

There is also a small risk that it's a compiler optimization gone wrong but I don't want to assume that quite yet.
Cc: thakis@chromium.org

Comment 7 by arj...@opera.com, Jul 20 2017

I notice this happens with component builds. For the case of CanvasRenderingContext.cpp, it looks like the vtable for blink::CanvasRenderingContext isn't exported in libblink_core.dylib (it exists but isn't exported, verified with 'nm'), so it can't be referenced from other libraries.

Moving the destructor definition to CanvasRenderingContext.cpp (so un-inlining it) will cause the vtable to be exported, making the problem disappear. I don't know why.
Components: Build

Sign in to add a comment