Issue with -faddress-sanitizer in combination with -Os/-O2 #20

ramosian-glider · 2015-08-31T14:07:01Z

Originally reported on Google Code with ID 20

I recently tried a Firefox+ASan build with optimization turned on. During startup I
saw an ASan abort due to a stack buffer overflow in libpng code (which only happens
in the optimized version). I inspected the code and it's impossible that an overflow
is happening at the given location.

However, I managed to extract a testcase and minimized it by automatic means with respect
to code and involved compiler flags. It turned out that the combination of -faddress-sanitizer
and -Os is the problem, -O2 produces the same. Using -O1 or -O0 though works. The test
is attached: To reproduce, unpack the archive, run "make" and then execute ./main.

Tested this on 64 bit with LLVM/Clang/compiler-rt revision 146212.


Main output is:

==25258== ERROR: AddressSanitizer stack-buffer-overflow on address 0x7fff94e82cb0 at
pc 0x4019ff bp 0x7fff94e82c50 sp 0x7fff94e82c48
READ of size 8 at 0x7fff94e82cb0 thread T0
    #0 0x4019ff (testAsanOptimizeSize/main+0x4019ff)
    #1 0x401929 (testAsanOptimizeSize/main+0x401929)
    #2 0x7f76bd049eff (/lib/x86_64-linux-gnu/libc-2.13.so+0x1eeff)
Address 0x7fff94e82cb0 is located at offset 48 in frame <test> of T0's stack:
  This frame has 1 object(s):
    [32, 54) 'data'


The function init just initializes the buffer while finish just prints the values.
I moved these to a separate compilation unit so the access isn't entirely optimized
away.

Reported by decoder.oh on 2011-12-16 14:17:28

- _Attachment: [testAsanOptimizeSize.tgz](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-20/comment-0/testAsanOptimizeSize.tgz)_

The text was updated successfully, but these errors were encountered:

ramosian-glider · 2015-08-31T14:07:08Z

First of all, thanks a lot for a high quality reproducer!

I suspected we may have this problem when we observed http://llvm.org/bugs/show_bug.cgi?id=11376,
but I was too lazy/busy to investigate further. 

This is a conflict of load widening and asan. 
We either need to disable load widening when asan is active, or disable such widening
completely. 
I'll ask at the LLVM mailing list about their opinion.



% cat load_widening.c && echo ========= && clang  -O2  -c  load_widening.c -flto &&
llvm-dis load_widening.o && cat load_widening.o.ll 
void init(char *);
int foo() {
  char a[22];
  init(a);
  return a[16] + a[21];
}
=========
; ModuleID = 'load_widening.o'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

define i32 @foo() nounwind uwtable {
entry:
  %a = alloca [22 x i8], align 16
  %arraydecay = getelementptr inbounds [22 x i8]* %a, i64 0, i64 0
  call void @init(i8* %arraydecay) nounwind
  %arrayidx = getelementptr inbounds [22 x i8]* %a, i64 0, i64 16
  %0 = bitcast i8* %arrayidx to i64*
  %1 = load i64* %0, align 16
  %2 = trunc i64 %1 to i32
  %sext = shl i32 %2, 24
  %conv = ashr exact i32 %sext, 24
  %3 = lshr i64 %1, 16
  %.tr = trunc i64 %3 to i32
  %sext3 = ashr i32 %.tr, 24
  %add = add nsw i32 %sext3, %conv
  ret i32 %add
}

declare void @init(i8*)


Even smaller repro: 

% cat main.c 
#include <string.h>

__attribute__((noinline))
void Init(unsigned char* buf, long bufsize) {
  memset(buf, 0xDA, bufsize);
}

int main(int argc, char **argv) {
  char data[22];
  Init(data, sizeof(data));
  return data[16] + data[21];
}
% clang -w -O2 -g    -faddress-sanitizer main.c && ./a.out  2>&1 | ./asan_symbolize.py
/
=================================================================
==22809== ERROR: AddressSanitizer stack-buffer-overflow on address 0x7fff8b3661b0 at
pc 0x401bad bp 0x7fff8b366170 sp 0x7fff8b366168
READ of size 8 at 0x7fff8b3661b0 thread T0
    #0 0x401bad in main main.c:11
    #1 0x7fdf3d594c4d in __libc_start_main libc-start.c:258
Address 0x7fff8b3661b0 is located at offset 48 in frame <main> of T0's stack:
  This frame has 1 object(s):
    [32, 54) 'data'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism
      (longjmp and C++ exceptions *are* supported)
==22809== ABORTING
Stats: 0M malloced (0M for red zones) by 3 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 3 calls
Stats: 0M really freed by 0 calls
Stats: 8M (2048 full pages) mmaped in 2 calls
  mmaps   by size class: 8:16383; 10:4095;
  mallocs by size class: 8:2; 10:1;
  frees   by size class: 8:2; 10:1;
  rfrees  by size class:
Stats: malloc large: 0 small slow: 2
Shadow byte and word:
  0x1ffff166cc36: 6
  0x1ffff166cc30: f1 f1 f1 f1 00 00 06 f4
More shadow bytes:
  0x1ffff166cc10: 00 00 00 00 00 00 00 00
  0x1ffff166cc18: 00 00 00 00 00 00 00 00
  0x1ffff166cc20: 00 00 00 00 00 00 00 00
  0x1ffff166cc28: 00 00 00 00 00 00 00 00
=>0x1ffff166cc30: f1 f1 f1 f1 00 00 06 f4
  0x1ffff166cc38: f3 f3 f3 f3 00 00 00 00
  0x1ffff166cc40: 00 00 00 00 00 00 00 00
  0x1ffff166cc48: 00 00 00 00 00 00 00 00
  0x1ffff166cc50: 00 00 00 00 00 00 00 00

Reported by konstantin.s.serebryany on 2011-12-16 18:12:30

Status changed: Accepted

ramosian-glider · 2015-08-31T14:07:16Z

Reported by konstantin.s.serebryany on 2011-12-16 18:12:43

ramosian-glider · 2015-08-31T14:07:24Z

Discussion: https://groups.google.com/group/llvm-dev/browse_thread/thread/24c297cff6aa1fbd/

Reported by konstantin.s.serebryany on 2011-12-17 00:06:46

ramosian-glider · 2015-08-31T14:07:32Z

i just tried firefox + asan from https://developer.mozilla.org/en/Building_Firefox_with_Address_Sanitizer.

Firefox is crashing on startup with following asan error log 


=================================================================
==18456== ERROR: AddressSanitizer stack-buffer-overflow on address 0xbfeaaac4 at pc
0xb0e4d157 bp 0xbfea9398 sp 0xbfea9394
READ of size 4 at 0xbfeaaac4 thread T0
    #0 0xb0e4d157 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135b3157)
    #1 0xb0e017b0 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135677b0)
    #2 0xb0e00dd0 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13566dd0)
    #3 0xb0e158ac (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1357b8ac)
    #4 0xb0e4315e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135a915e)
    #5 0xb0e41fb3 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135a7fb3)
    #6 0xb0e255d3 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1358b5d3)
    #7 0xb0e1b2e7 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x135812e7)
    #8 0xb0e19ed7 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1357fed7)
    #9 0xb08144ef (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x12f7a4ef)
    #10 0xa4d67ade (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x74cdade)
    #11 0xa4d27f39 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x748df39)
    #12 0xa49e1802 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x7147802)
    #13 0xa48ba6df (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x70206df)
    #14 0xb13ef3f5 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b553f5)
    #15 0xb13a4036 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b0a036)
    #16 0xb13b0b1e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b16b1e)
    #17 0xb13afe51 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13b15e51)
    #18 0xb1113a3b (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13879a3b)
    #19 0xb10e0447 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13846447)
    #20 0xb11c038c (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1392638c)
    #21 0xb0a5c48e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x131c248e)
    #22 0xb0d90b3c (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x134f6b3c)
    #23 0xb11fa813 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13960813)
    #24 0xb11bfec7 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13925ec7)
    #25 0xb111f6ba (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x138856ba)
    #26 0xb10e0447 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13846447)
    #27 0xb11c038c (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x1392638c)
    #28 0xb0a5c48e (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x131c248e)
    #29 0xb11c3e82 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13929e82)
    #30 0xb08b3ffa (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x13019ffa)
    #31 0xa8742bdb (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xaea8bdb)
    #32 0xa86e32ee (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xae492ee)
    #33 0xad66aca5 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xfdd0ca5)
    #34 0xa30a98a1 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x580f8a1)
    #35 0xa30aaf68 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5810f68)
    #36 0xa32f0e69 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a56e69)
    #37 0xa32d9b4a (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a3fb4a)
    #38 0xa32d6b27 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a3cb27)
    #39 0xa32de0f2 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x5a440f2)
    #40 0xa02c484d (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x2a2a84d)
    #41 0xa02ca5aa (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x2a305aa)
    #42 0xa02bb2a4 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x2a212a4)
    #43 0xa4c75cf1 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x73dbcf1)
    #44 0xa4c4e4eb (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0x73b44eb)
    #45 0xab3e9343 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdb4f343)
    #46 0xab429f4a (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdb8ff4a)
    #47 0xab458ec0 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdbbeec0)
    #48 0x2e26284 (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x135284)
    #49 0xd5e412 (/usr/lib/libgobject-2.0.so.0.2600.1+0xc412)
    #50 0xd74b85 (/usr/lib/libgobject-2.0.so.0.2600.1+0x22b85)
    #51 0xd75e2b (/usr/lib/libgobject-2.0.so.0.2600.1+0x23e2b)
    #52 0xd76452 (/usr/lib/libgobject-2.0.so.0.2600.1+0x24452)
    #53 0x2f54b96 (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x263b96)
    #54 0x2e1e85d (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x12d85d)
    #55 0x2e1fed7 (/usr/lib/libgtk-x11-2.0.so.0.2200.0+0x12eed7)
    #56 0xe0f36a (/usr/lib/libgdk-x11-2.0.so.0.2200.0+0x5636a)
    #57 0xb34855 (/lib/libglib-2.0.so.0.2600.1+0x3d855)
    #58 0xb38668 (/lib/libglib-2.0.so.0.2600.1+0x41668)
    #59 0xb38848 (/lib/libglib-2.0.so.0.2600.1+0x41848)
    #60 0xab499356 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdbff356)
    #61 0xab5ed349 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdd53349)
    #62 0xab5efd59 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdd55d59)
    #63 0xab5f1984 (/home/cons0ul/code/mozsrc/objdir-ff-asan/toolkit/library/libxul.so+0xdd57984)
Address 0xbfeaaac4 is located at offset 324 in frame <_ZL7GCCycleP9JSContextP13JSCompartment18JSGCInvocationKind>
of T0's stack:
  This frame has 11 object(s):
    [32, 36) 'cx.addr'
    [96, 100) 'comp.addr'
    [160, 164) 'gckind.addr'
    [224, 228) 'rt'
    [288, 292) 'gcsession'
    [352, 356) 'exn.slot'
    [416, 420) 'ehselector.slot'
    [480, 484) 'cleanup.dest.slot'
    [544, 556) 'sc'
    [608, 612) 'ref.tmp'
    [672, 680) 'c'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism
      (longjmp and C++ exceptions *are* supported)
==18456== ABORTING
Stats: 1225M malloced (692M for red zones) by 531899 calls
Stats: 1038M realloced by 44032 calls
Stats: 1152M freed by 304584 calls
Stats: 985M really freed by 267103 calls
Stats: 1004M (257237 full pages) mmaped in 248 calls
  mmaps   by size class: 8:278511; 9:49146; 10:20475; 11:14329; 12:2048; 13:2560; 14:1536;
15:384; 16:448; 17:192; 18:128; 19:80; 20:132; 21:120; 22:70; 23:3; 
  mallocs by size class: 8:426805; 9:55405; 10:22657; 11:17262; 12:1946; 13:3584; 14:1576;
15:470; 16:584; 17:323; 18:291; 19:217; 20:378; 21:302; 22:94; 23:5; 
  frees   by size class: 8:213957; 9:48134; 10:20286; 11:15205; 12:1544; 13:1630; 14:1457;
15:423; 16:495; 17:214; 18:259; 19:211; 20:377; 21:300; 22:89; 23:3; 
  rfrees  by size class: 8:186881; 9:42620; 10:17703; 11:13348; 12:1507; 13:1540; 14:1443;
15:408; 16:473; 17:192; 18:227; 19:146; 20:263; 21:262; 22:87; 23:3; 
Stats: malloc large: 1610 small slow: 2471
Shadow byte and word:
  0x37fd5558: f2
  0x37fd5558: f2 f2 f2 f2
More shadow bytes:
  0x37fd5548: f2 f2 f2 f2
  0x37fd554c: 04 f4 f4 f4
  0x37fd5550: f2 f2 f2 f2
  0x37fd5554: 04 f4 f4 f4
=>0x37fd5558: f2 f2 f2 f2
  0x37fd555c: 04 f4 f4 f4
  0x37fd5560: f2 f2 f2 f2
  0x37fd5564: 04 f4 f4 f4
  0x37fd5568: f2 f2 f2 f2


is this because of the above issue ?

Reported by sachinshinde11 on 2012-01-04 22:10:09

ramosian-glider · 2015-08-31T14:07:39Z

This seems to be a different issue (either a real bug in FF, or another bug in asan).
I suggest we discuss it in [email protected] or in a new bug. 
Let's start from symbolizing the output and looking at the FF source code.

Reported by [email protected] on 2012-01-04 22:20:40

ramosian-glider · 2015-08-31T14:07:47Z

I hope this is finally fixed by llvm r149925.

Reported by konstantin.s.serebryany on 2012-02-06 22:54:46

Status changed: Fixed

ramosian-glider · 2015-08-31T14:07:55Z

Adding Project:AddressSanitizer as part of GitHub migration.

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

Labels added: ProjectAddressSanitizer

ramosian-glider assigned google Aug 31, 2015

ramosian-glider added Type-Defect Priority-Medium ProjectAddressSanitizer Status-Fixed labels Aug 31, 2015

ramosian-glider closed this as completed Aug 31, 2015

daliands mentioned this issue Jul 11, 2016

LargeMmapAllocator problem #697

Closed

djdeath mentioned this issue Feb 24, 2017

Early segfaults in __tsan::TraceAddEvent #772

Closed

adubovkin mentioned this issue Mar 8, 2018

Boot loop after asan_device_setup on Android 6.0.1 #923

Open

dionescu mentioned this issue May 9, 2018

TSAN false positives with chromium clang toolchain #953

Open

shubhamgarg1 mentioned this issue Mar 2, 2019

Error when trying to use Address Sanitizer on Android #1057

Open

karen-arutyunov mentioned this issue Jun 6, 2019

ubsan IsAccessibleMemoryRange use of pipe causes tsan false positives #1106

Open

sarora5 mentioned this issue Jun 12, 2019

ASAN is crashing app_process on Android #1101

Open

kusumakara mentioned this issue Jun 26, 2019

AddressSanitizer on a android application. #1100

Closed

ramosian-glider unassigned google Oct 14, 2019

ramosian-glider mentioned this issue Jan 18, 2020

ThreadSanitizer crashes with CHECK on very simple std::async test on Android #1183

Open

oviano mentioned this issue Mar 31, 2020

Possible issue with Android ASan and std::thread? #1216

Open

kulkrohit mentioned this issue Oct 30, 2020

TSAN Segmentation fault : GCC 9.1.0, libtsan, centOS 6 #1338

Open

kdbghelp mentioned this issue Oct 26, 2021

AddressSanitizer failed to allocate on iOS devices #1458

Open

OldChicken1 mentioned this issue Jul 14, 2022

TSAN Segmentation fault #1551

Open

chaiken mentioned this issue Dec 26, 2022

ASAN SEGV's on mixed C++-C unit googletest #1601

Open

koteswararao18 mentioned this issue Aug 6, 2023

asan: triggered deadley signal for clang-14.0.6 built application #1673

Closed

UjjwalChitransh mentioned this issue Apr 3, 2024

Debugging C++ Segmentation Fault in Leak Sanitizer - Need Help with Backtrace Analysis #1740

Open

eugenis mentioned this issue Apr 24, 2024

Workarounds for #837 (Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.) #856

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue with -faddress-sanitizer in combination with -Os/-O2 #20

Issue with -faddress-sanitizer in combination with -Os/-O2 #20

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

Issue with -faddress-sanitizer in combination with -Os/-O2 #20

Issue with -faddress-sanitizer in combination with -Os/-O2 #20

Comments

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015

ramosian-glider commented Aug 31, 2015