CHECK failed error in pdfium_test binary

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ninja -C out/Release pdfium_test
2. out/Release/pdfium_test a.pdf 2>&1 | tools/valgrind/asan/asan_symbolize.py

What is the expected output? What do you see instead?

Expect run successfully with a normal pdf document.
Instead see the following error:

==616==AddressSanitizer CHECK failed: 
/usr/local/google/work/chromium/src/third_party/llvm/projects/compiler-rt/lib/as
an/asan_globals.cc:93 "((AddrIsAlignedByGranularity(g->beg))) != (0)" (0x0, 0x0)
    #0 0x4ab7d3 in __asan::AsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) _asan_rtl_:0
    #1 0x4b1f71 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /usr/local/google/work/chromium/src/third_party/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_common.cc:76:0
    #2 0x448933 in RegisterGlobal _asan_rtl_:0    #3 0x448933 in __asan_register_globals _asan_rtl_:0
    #4 0x7fcf715b8c4e in asan.module_ctor ??:0:0
    #5 0x7fcf7209d315 in call_init /build/buildd/eglibc-2.15/elf/dl-init.c:85:0
    #6 0x7fcf7209d3ee in call_init /build/buildd/eglibc-2.15/elf/dl-init.c:52:0    #7 0x7fcf7209d3ee in _dl_init /build/buildd/eglibc-2.15/elf/dl-init.c:134:0
    #8 0x7fcf7208f6f9 in ?? ??:0

What version of the product are you using? On what operating system?
Using the latest pdfium and chromium checkout

Please provide any additional information below.
ASan worked fine with pdfium before. What looks weird is the path 
"/usr/local/google/work/chromium/src/third_party/..." is invalid. It should be 
"/home/account_name/src/third_party/..."

Also, running base_unittests does not generate this error.

Original issue reported on code.google.com by bo...@foxitsoftware.com on 26 Jul 2014 at 6:45

[GoogleCodeExporter]

I can reproduce it. 

ASAN_OPTIONS=report_globals=2 out/Release/pdfium_test a

==25590==Added Global: beg=0x7f08feeb8360 size=15/64 name=.str 
module=../../third_party/libc++abi/trunk/src/exception.cpp dyn_init=0
==25590==Added Global: beg=0x7f08feeb83a0 size=19/64 name=.str1 
module=../../third_party/libc++abi/trunk/src/exception.cpp dyn_init=0
==25590==Added Global: beg=0x7f08feedc100 size=40/96 name=_ZTVSt9exception 
module=../../third_party/libc++abi/trunk/src/exception.cpp dyn_init=0
==25590==Added Global: beg=0x000001d03b01 size=13/64 name=_ZTSSt9exception 
module=../../third_party/libc++abi/trunk/src/exception.cpp dyn_init=0
==25590==AddressSanitizer CHECK failed: 
/usr/local/google/work/chromium/src/third_party/llvm/projects/compiler-rt/lib/as
an/asan_globals.cc:93 "((AddrIsAlignedByGranularity(g->beg))) != (0)" (0x0, 0x0)

The address of _ZTSSt9exception is clearly wrong. 

% nm out/Release/pdfium_test  | grep  _ZTSSt9exception
0000000001d03b01 V _ZTSSt9exception

We force alignment of instrumented variables to 8, but this one ends with ...01

bo_xu@, as a temporary workaround, please try 
ASAN_OPTIONS=report_globals=0 out/Release/pdfium_test a

Original comment by konstant...@gmail.com on 28 Jul 2014 at 7:17

• Changed state: Accepted

[GoogleCodeExporter]

Here're three modules that declare _ZTSSt9exception (aside from libc++.so in 
which _ZTSSt9exception is aligned):

obj/third_party/pdfium/fpdfsdk/src/javascript/javascript.Field.o:
0000000000000000 V _ZTSSt9exception
obj/third_party/pdfium/fpdfsdk/src/javascript/javascript.PublicMethods.o:
0000000000000000 V _ZTSSt9exception
obj/third_party/pdfium/fpdfsdk/src/javascript/javascript.util.o:
0000000000000000 V _ZTSSt9exception

Original comment by ramosian.glider@gmail.com on 28 Jul 2014 at 8:42

[GoogleCodeExporter]

When I build third_party/libc++abi/trunk/src/exception.cpp without ASan, 
@_ZTSSt9exception is declared as regular constant:

@_ZTSSt9exception = constant [13 x i8] c"St9exception\00"

, and is thus instrumented.

Whereas for third_party/pdfium/fpdfsdk/src/javascript/Field.cpp w/o ASan 
@_ZTSSt9exception is a linkonce_odr constant:

@_ZTSSt9exception = linkonce_odr constant [13 x i8] c"St9exception\00"

There must be a mismatch between the declaration of std::exception in the 
header and in exception.cpp

Original comment by ramosian.glider@gmail.com on 28 Jul 2014 at 8:59

[GoogleCodeExporter]

Any update on this one? What we can do to remedy this issue at this moment? 
Thanks!

Original comment by bo...@foxitsoftware.com on 4 Aug 2014 at 6:20

[GoogleCodeExporter]

Sorry, no update yet (we've been distracted by vacations and travel). 
As a workaround please use 
  ASAN_OPTIONS=report_globals=0 out/Release/pdfium_test a

Original comment by konstant...@gmail.com on 4 Aug 2014 at 7:54

[GoogleCodeExporter]

Reduced test case: 

% cat a1.cc
struct AAA {
 public:
#if DTOR
  virtual ~ AAA ();
#endif
};
#if DTOR
AAA::~AAA() { }
#endif
void foo () { throw AAA (); }

% clang++ a1.cc -std=c++11 -S -o - -emit-llvm  -DDTOR=0  | grep _ZTI3AAA.=
@_ZTI3AAA = linkonce_odr constant { i8*, i8* } { i8* bitcast (i8** 
getelementptr inbounds (i8** @_ZTVN10__cxxabiv117__class_type_infoE, i64 2) to 
i8*), i8* getelementptr inbounds ([5 x i8]* @_ZTS3AAA, i32 0, i32 0) }

% clang++ a1.cc -std=c++11 -S -o - -emit-llvm  -DDTOR=1  | grep _ZTI3AAA.=
@_ZTI3AAA = constant { i8*, i8* } { i8* bitcast (i8** getelementptr inbounds 
(i8** @_ZTVN10__cxxabiv117__class_type_infoE, i64 2) to i8*), i8* getelementptr 
inbounds ([5 x i8]* @_ZTS3AAA, i32 0, i32 0) }
% 

So, depending on whether the DTOR is inlined or not, the symbol is either ODR 
or nor, which makes asan behave differently.
Time to ask clang folks for help. 

Original comment by konstant...@gmail.com on 5 Aug 2014 at 8:49

[GoogleCodeExporter]

bo_xu, can you still reproduce the problem with the fresh trunk? 
I can't: 
ASAN_OPTIONS=report_globals=2 ./out/Release/pdfium_test a 2>&1  | grep 
_ZTSSt9exception
==6265==Added Global[0x7f5e8e46dba8]: beg=0x7f5e8e433bc0 size=13/64 
name=_ZTSSt9exception 
module=../../third_party/libc++abi/trunk/src/exception.cpp dyn_init=0

Note: 0x7f5e8e433bc0 is properly aligned. 

Original comment by konstant...@gmail.com on 15 Aug 2014 at 9:25

[GoogleCodeExporter]

I cannot reproduce either. Seems this is fixed.

Original comment by bo...@foxitsoftware.com on 16 Aug 2014 at 8:14

[GoogleCodeExporter]

I am not convinced this is fixed, but since we can't repro I am closing it now. 
Please reopen if you see this again. 
Also, if you used the workaround to disable asan checks for globals, please 
remove it.  

Original comment by konstant...@gmail.com on 21 Aug 2014 at 3:54

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for the info!

Original comment by bo...@foxitsoftware.com on 21 Aug 2014 at 4:01