Address-sanitizer reports false global-buffer-overflow

[GoogleCodeExporter]

Address-sanitizer reports a global-buffer-overflow, when I execute the 
following C-code:

section_main.c:
#include <stdio.h>
#include <string.h>
#include "section.h"

extern My_data __start_my_section;
extern My_data __stop_my_section;

My_data *person = &__start_my_section;
My_data *person_last = &__stop_my_section;
int i = 1;

int main (void) {
   while (person < person_last) {
      if (strcmp(person->name, "Fred") == 0)
         printf("Position of person %s is: %i\n", person->name, i);
      i++; person++;
   }
}

section.c:
#include "section.h"

__attribute__((section("my_section"))) My_data person1 = {.name = "Klaus"};
__attribute__((section("my_section"))) My_data person2 = {.name = "Peter"};
__attribute__((section("my_section"))) My_data person3 = {.name = "Fred"};

section.h:
typedef struct my_data {
   char name[20];
 } My_data;

There is no real global-buffer-overflow. The reported global-buffer-overflow is 
caused by the instrumentation. I haven't found any way to switch off the 
instrumentation for this code. Also the black-list feature didn't help. 

I use Unbuntu 14.04 LTS:

Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: i386-pc-linux-gnu

The error report from address-sanitizer is:

=================================================================
==4784==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080e3ad4 
at pc 0x80785a8 bp 0xbfcf1f78 sp 0xbfcf1f68
READ of size 1 at 0x080e3ad4 thread T0
    #0 0x80785a7 in __interceptor_strcmp (/home/stefan/Sanitizer/example/section.sct+0x80785a7)
    #1 0x80ca4fa in main (/home/stefan/Sanitizer/example/section.sct+0x80ca4fa)

0x080e3ad4 is located 44 bytes to the left of global variable 'person2' from 
'section.c' (0x80e3b00) of size 20
0x080e3ad4 is located 0 bytes to the right of global variable 'person1' from 
'section.c' (0x80e3ac0) of size 20
SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 __interceptor_strcmp
Shadow bytes around the buggy address:
  0x2101c700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2101c710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2101c720: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x2101c730: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x2101c740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x2101c750: 00 00 00 00 00 00 00 00 00 00[04]f9 f9 f9 f9 f9
  0x2101c760: 00 00 04 f9 f9 f9 f9 f9 00 00 04 f9 f9 f9 f9 f9
  0x2101c770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2101c780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2101c790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2101c7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==4784==ABORTING

Original issue reported on code.google.com by stefan.p...@gmail.com on 9 Nov 2014 at 8:35

[GoogleCodeExporter]

I think you can't rely on MyData instances to be adjacent to each other in 
my_section. For example my compiler (x86_64-pc-cygwin GCC) inserts 16-byte 
alignment after each instance.

Original comment by tetra2...@gmail.com on 9 Nov 2014 at 9:12

[GoogleCodeExporter]

This is clearly working as intended -- asan finds a real bug. 
Nothing in the C/C++ standard guarantees that the globals will be emitted the 
way this code expects.

To silence this report simply compile section.c w/o asan. 

Original comment by konstant...@gmail.com on 10 Nov 2014 at 5:20

• Changed state: WontFix

[GoogleCodeExporter]

> To silence this report simply compile section.c w/o asan.

Although I wouldn't recommend this - the code can only work by pure accident.

Original comment by tetra2...@gmail.com on 10 Nov 2014 at 5:53