New issue
Advanced search Search tips

Issue 832808 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Apr 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Linux: AddressSanitizer: odr-violation: global 'typeinfo name for std::exception'

Project Member Reported by marshall@chromium.org, Apr 13 2018

Issue description

Chrome Version: Master revision 66afc5e5 (#540276, M66 branch point)
OS: Ubuntu 14.04.04 and 16.04.04

What steps will reproduce the problem?
(1) Build a Content API-based application with the below GN args.
(2) Run the application

What is the expected result?
The application should run.

What happens instead?
The application fails with the following error:

==10466==The following global variable is not properly aligned.
==10466==This may happen if another global with the same name
==10466==resides in another non-instrumented module.
==10466==Or the global comes from a C file built w/o -fno-common.
==10466==In either case this is likely an ODR violation bug,
==10466==but AddressSanitizer can not provide more details.
=================================================================
==10466==ERROR: AddressSanitizer: odr-violation (0x7f8ef43126cd):
  [1] size=13 'typeinfo name for std::exception' ../../buildtools/third_party/libc++abi/trunk/src/stdlib_exception.cpp
  [2] size=13 'typeinfo name for std::exception' ../../buildtools/third_party/libc++abi/trunk/src/stdlib_exception.cpp
These globals were registered at these points:
  [1]:
    #0 0x2ca4ee  (/home/marshall/code/chromium_git/chromium/src/out/Release_GN_x64/cefsimple+0x2ca4ee)
    #1 0x7f8ef127031b  (/home/marshall/code/chromium_git/chromium/src/out/Release_GN_x64/./libc++.so+0x1d731b)

  [2]:
    #0 0x2ca4ee  (/home/marshall/code/chromium_git/chromium/src/out/Release_GN_x64/cefsimple+0x2ca4ee)
    #1 0x7f8ef127031b  (/home/marshall/code/chromium_git/chromium/src/out/Release_GN_x64/./libc++.so+0x1d731b)

==10466==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'typeinfo name for std::exception' at ../../buildtools/third_party/libc++abi/trunk/src/stdlib_exception.cpp
==10466==ABORTING

Please use labels and text to provide additional information.

The problem does not reproduce with this application at master revision bc084a8b (#530369, M65 branch point). The problem does not reproduce with the content_shell application at either revision.

GN args:

dcheck_always_on=true
enable_linux_installer=false
enable_nacl=false
enable_widevine=true
fatal_linker_warnings=false
is_asan=true
is_component_build=false
is_debug=false
target_cpu="x64"
use_gtk3=false
use_jumbo_build=true
use_sysroot=false

GN target configuration: https://bitbucket.org/chromiumembedded/cef/src/87e33b16922158422d50ee6085e4f91888b83b91/BUILD.gn?at=master&fileviewer=file-view-default#BUILD.gn-1899

executable("cefsimple") depends on shared_library("libcef") depends on static_library("libcef_static").

I've tried adding "//build/config:exe_and_shlib_deps" as a deps for all of these targets but it did not resolve the error.

Could this error be caused by some target statically linking libc++? Is there a GN configuration or target in Chromium that statically links libc++ and might be an indirect deps for one of these targets?
 
Owner: thomasanderson@chromium.org
Status: Assigned (was: Untriaged)
This is a known clang bug
https://bugs.llvm.org/show_bug.cgi?id=35066

For now, you can probably workaround the issue by changing shared_library("libcef") to component("libcef").
@thomasanderson: Thanks for the link. Are you aware of any potential workarounds that would not require converting shared_library("libcef") to a static_library or source_set? That conversion would be complicated for CEF due to the way that we export/import our API symbols.
> That conversion would be complicated for CEF due to the way that we export/import our API symbols.

To be more specific, shared_library("libcef") exports a C API which is then imported by static_library("libcef_dll_wrapper") that clients depend on. Internally, "libcef" has the same symbol names as "libcef_dll_wrapper", so statically linking "libcef" with the client application would result in many duplicate symbol errors. To fix this we would probably need to move all "libcef" symbols into a different namespace, which is a pretty big code change.
Chrome has a linker version script to control exactly which symbols are allowed to be exported
https://cs.chromium.org/chromium/src/build/linux/chrome.map?rcl=c039aa885524b093f351c33acd3170b57d4feee3&l=1

You could add a version script to one or both of cefsimple and libcef to prevent the typeinfo symbols from getting exported.
Status: Verified (was: Assigned)
Thanks, using a version script for libcef fixes the error :)

Sign in to add a comment