ramosian-glider / sanitizers

0 stars 0 forks source link

AddrIsAlignedByGranularity CHECK fails #83

Closed ramosian-glider closed 9 years ago

ramosian-glider commented 9 years ago

Originally reported on Google Code with ID 82

What steps will reproduce the problem?

1. Compile any binary with Clang+Asan on my Snow Leopard system

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

It should launch.

But I get :

==33970== CHECK failed: AddrIsAlignedByGranularity(g->beg) at /private/tmp/llvm/projects/compiler-rt/lib/asan/asan_globals.cc:111
   #0 0x66e7 (/tmp/mybinary+0x56e7)
   #1 0x344c (/tmp/mybinary+0x244c)
   #2 0x8fe0ed69
   #3 0x8fe0d31a
   #4 0x8fe0d2be
   #5 0x8fe0d2be
   #6 0x8fe0d3cd
   #7 0x8fe024a9
   #8 0x8fe0794e
   #9 0x8fe018b1
   #10 0x8fe01057
   #11 0x1000 (/tmp/mybinary+0x0)
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0 full pages) mmaped in 0 calls
 mmaps   by size class:
 mallocs by size class:
 frees   by size class:
 rfrees  by size class:
Stats: malloc large: 0 small slow: 0

What version of the product are you using? On what operating system?

clang version 3.2 (trunk 156816)
Target: x86_64-apple-darwin9.8.0
Thread model: posix

I even tried latest trunk same behavior.
Also all the tests succeeded.

Please provide any additional information below.

The binary is compiled in 32bit.
I have set in my environment DYLD_NO_PIE=1

Excerpt from sysctl :

kern.version = Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64

hw.machine = x86_64
hw.model = MacPro5,1
hw.ncpu = 8
hw.byteorder = 1234
hw.physmem = 2147483648
hw.usermem = 1331470336
hw.pagesize = 4096

Reported by mkvtoolnix.build.jonthn on 2012-06-22 14:05:43

ramosian-glider commented 9 years ago

Reported by konstantin.s.serebryany on 2012-06-22 16:32:54

ramosian-glider commented 9 years ago
Do you see this with projects/compiler-rt/lib/asan/output_tests/global-overflow.cc ?

What is the exact command line? 

Please try running like
  ASAN_OPTIONS=verbosity=1:report_globals=2  ./a.out
and paste the output here. 

Maybe play with the code in RegisterGlobal/asan/asan_globals.cc to put the report before
the checks. 

Reported by konstantin.s.serebryany on 2012-06-25 05:55:44

ramosian-glider commented 9 years ago
I think I've encountered this problem with Chromium last week, but our tests do work,
so this is not about any binary.
I'm going to take a look asap.

Reported by ramosian.glider on 2012-06-25 08:45:35

ramosian-glider commented 9 years ago
The problem does not reproduce for me neither on ASan tests nor on Chromium.
Can you please provide a reproducer?

Reported by ramosian.glider on 2012-06-26 15:49:25

ramosian-glider commented 9 years ago
The bug is not actionable. 
Please reopen when you have a repro. 

Reported by konstantin.s.serebryany on 2012-06-27 06:59:31

ramosian-glider commented 9 years ago
Sorry for not responding earlier, I currently do not have access to the machine with
the problem, if later I can reproduce it with a simpler code I'll share it here.

Reported by mkvtoolnix.build.jonthn on 2012-06-28 15:32:47

ramosian-glider commented 9 years ago
Looks like the crash is reproducible on Webkit DumpRenderTree.app built from the Chromium
tree. Taking a look.

Reported by ramosian.glider on 2012-07-09 08:46:17

ramosian-glider commented 9 years ago
When DRT is built with component=static_library, everything is fine:

$ out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree
#EOF

If I build with component=shared_library the crash occurs:

$ out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree 
objc[60195]: Class MockCrApp is implemented in both /Users/glider/src/chrome-commit-copy/src/out/Release/DumpRenderTree.app/Contents/MacOS/../../../libwebkit.dylib
and /Users/glider/src/chrome-commit-copy/src/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree.
One of the two will be used. Which one is undefined.
==60195== AddressSanitizer CHECK failed: /Users/glider/src/asan/llvm/projects/compiler-rt/lib/asan/asan_globals.cc:111
"((AddrIsAlignedByGranularity(g->beg))) != (0)" (0, 0)
    #0 0x2392a5 (/Users/glider/src/chrome-commit-copy/src/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree+0x2382a5)
    #1 0x23276e (/Users/glider/src/chrome-commit-copy/src/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree+0x23176e)
    #2 0x8fe0ed69
    #3 0x8fe0d31a
    #4 0x8fe0d2be
    #5 0x8fe0d2be
    #6 0x8fe0d3cd
    #7 0x8fe024a9
    #8 0x8fe0794e
    #9 0x8fe018b1
    #10 0x8fe01057
    #11 0x1000 (/Users/glider/src/chrome-commit-copy/src/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree+0x0)
Stats: 0M malloced (2M for red zones) by 8445 calls
Stats: 0M realloced by 449 calls
Stats: 0M freed by 5421 calls
Stats: 0M really freed by 0 calls
Stats: 36M (9221 full pages) mmaped in 9 calls
  mmaps   by size class: 8:16383; 9:8191; 10:4095; 11:2047; 12:1024; 13:512; 14:256;
15:128; 16:64; 
  mallocs by size class: 8:8245; 9:123; 10:12; 11:8; 12:2; 13:38; 14:10; 15:5; 16:2;

  frees   by size class: 8:5290; 9:77; 10:8; 11:2; 12:1; 13:31; 14:9; 15:2; 16:1; 
  rfrees  by size class: 
Stats: malloc large: 4 small slow: 29

Reported by ramosian.glider on 2012-07-09 09:26:08

ramosian-glider commented 9 years ago
I've figured out that compiling CCOcclusionTrackerTest.cpp from Webkit without instrumenting
globals fixes the issue with DumpRenderTree.
The file itself is quite large and hard to reduce, but the following piece of the globals
list rings the bell:

@1720 = private global [1720 x { i32, i32, i32, i32 }] [{ i32, i32, i32, i32 } { i32
ptrtoint ({ %"class.std::ios_base::Init", [63 x i8] }* @_ZStL8__ioinit to i32), i32
1, i32 64, i32 ptrtoint ([49 x i8]* @0 to i32) }, { i32, i32, i32, i32 } { i32 ptrtoint
({ %"class.testing::TestInfo"*, [60 x i8] }* @_ZN12_GLOBAL__N_175CCOcclusionTrackerTestIdentityTransformsMainThreadOpaqueLayers_runTest_Test10test_info_E
to i32), i32 4, i32 64, i32 ptrtoint ([142 x i8]* @1 to i32) }, { i32, i32, i32, i32
} { i32 ptrtoint ({ [63 x i8], [33 x i8] }* @.str to i32), i32 63, i32 96, i32 ptrtoint
([39 x i8]* @2 to i32) }, { i32, i32, i32, i32 } { i32 ptrtoint ({ [8 x i8], [56 x
i8] }* @.str2 to i32), i32 8, i32 64, i32 ptrtoint ([40 x i8]* @3 to i32) }, { i32,
i32, i32, i32 } { i32 ptrtoint ({ %"class.testing::TestInfo"*, [60 x i8] }* @_ZN12_GLOBAL__N_175CCOcclusionTrackerTestIdentityTransformsMainThreadOpaquePaints_runTest_Test10test_info_E
to i32), i32 4, i32 64, i32 ptrtoint ([142 x i8]* @4 to i32) }, {...

I suppose the problem is that _ZStL8__ioinit is being treated as a 1-byte global with
a redzone:

%"class.std::ios_base::Init" = type { i8 }
@_ZStL8__ioinit = internal global { %"class.std::ios_base::Init", [63 x i8] } zeroinitializer,
align 32

 while it shouldn't be:

    class Init
    {   
      friend class ios_base;
    public:
      Init();
      ~Init();

    private:
      static _Atomic_word       _S_refcount;
      static bool               _S_synced_with_stdio;
    }; 

Reported by ramosian.glider on 2012-07-09 15:21:16

ramosian-glider commented 9 years ago
$ cat t.c
#include <stdio.h>
#include <dlfcn.h>
int main() {
  void *handle = dlopen("/Users/glider/src/chrome-commit-copy/src/out/Release/libwebkit.dylib",
RTLD_NOW);
  if (!handle) {
    printf("Error: %s\n", dlerror());
  }
  printf("Handle: %p\n", handle);
  return 0;
}
$ ./t
...
==5587== Adding Global: g=0x0986e1e0 ==5587== beg=0x0993edc0 ==5587== size=20 ==5587==
name=_ZTVN7testing8internal15TestFactoryImplIN12_GLOBAL__N_151CCLayerTreeHostTestShortlived2_runSingleThread_TestEEE
(../../third_party/WebKit/Source/WebKit/chromium/tests/CCLayerTreeHostTest.cpp)
==5587== Adding Global: g=0x0986e1f0 ==5587== beg=0x0993ee00 ==5587== size=124 ==5587==
name=_ZTVN12_GLOBAL__N_151CCLayerTreeHostTestShortlived2_runSingleThread_TestE (../../third_party/WebKit/Source/WebKit/chromium/tests/CCLayerTreeHostTest.cpp)
==5587== Adding Global: g=0x04cc7ce0 ==5587== beg=0x85000005 ==5587== size=2303227072
==5587== name=c
==5587== AddressSanitizer CHECK failed: /Users/glider/src/asan/llvm/projects/compiler-rt/lib/asan/asan_globals.cc:117
"((AddrIsAlignedByGranularity(g->beg))) != (0)" (0, 0)
    #0 0xda85 (/Users/glider/src/chrome-commit-copy/src/./t+0xca85)
    #1 0x67ae (/Users/glider/src/chrome-commit-copy/src/./t+0x57ae)
    #2 0x8fe0ed69
    #3 0x8fe0d31a
    #4 0x8fe0d3cd
    #5 0x8fe0200b
    #6 0x8fe0b297
    #7 0x9569d2a8 (/usr/lib/libSystem.B.dylib+0x72a8)
    #8 0x2175 (/Users/glider/src/chrome-commit-copy/src/./t+0x1175)
    #9 0x2095 (/Users/glider/src/chrome-commit-copy/src/./t+0x1095)
    #10 0x1 (/Users/glider/src/chrome-commit-copy/src/./t+0x1)

Reported by ramosian.glider on 2012-07-10 09:17:33

ramosian-glider commented 9 years ago

Reported by glider@chromium.org on 2012-08-29 16:58:55

ramosian-glider commented 9 years ago
Jonathan, have you managed to reproduce the problem?

Reported by ramosian.glider on 2012-08-29 17:16:13

ramosian-glider commented 9 years ago
Unfortunately no, I didn't find a simple code that shows the problem.
I'll recheck next week if I still have the problem with ToT Asan build.

Reported by mkvtoolnix.build.jonthn on 2012-08-31 18:35:23

ramosian-glider commented 9 years ago
Any progress with reproducing this?

Reported by ramosian.glider on 2013-02-07 16:04:25

ramosian-glider commented 9 years ago
I wasn't able to reproduce it, sorry.

Reported by mkvtoolnix.build.jonthn on 2013-02-09 09:40:01

ramosian-glider commented 9 years ago
old bug w/o a repro. Please reopen if you see this again with fresh clang. 

Reported by konstantin.s.serebryany on 2013-02-15 14:26:03

ramosian-glider commented 9 years ago
I still don't have a repro.
But I encountered this again with fresh Clang+Asan (3.4 rev 184857)

==65120==Added Global: beg=0xc1156560 size=25/64 name=.str186 module=abc.c dyn_init=0
==65120==Added Global: beg=0x001fa8a4 size=4/64 name=logfile module=lib/zef.c dyn_init=0
==65120==AddressSanitizer CHECK failed: llvm/projects/compiler-rt/lib/asan/asan_globals.cc:93
"((AddrIsAlignedByGranularity(g->beg))) != (0)" (0x0, 0x0)

Reported by mkvtoolnix.build.jonthn on 2013-06-27 08:37:31

ramosian-glider commented 9 years ago
Perhaps this is an instance of
https://code.google.com/p/address-sanitizer/issues/detail?id=171 ?
Right now we disable globals instrumentation on Mac using '-mllvm -asan-globals=0'
I hope to get to that bug soon.

Reported by ramosian.glider on 2013-06-27 08:50:19

ramosian-glider commented 9 years ago
Alex, do we still have this? 

Reported by konstantin.s.serebryany on 2013-10-03 13:39:00

ramosian-glider commented 9 years ago
Closing since there is not reproducer and since a related issue 171 is fixed.
Please reopen if you have a reproducer. 

Reported by konstantin.s.serebryany on 2013-12-26 14:47:22

ramosian-glider commented 9 years ago
Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:59