[Bug c++/62017] New: AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used

["bezkrovatki at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62017

            Bug ID: 62017
           Summary: AddressSanitizer reports *-buffer-overflow in
                    destructor when multiple virtual inheritance is used
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bezkrovatki at gmail dot com

Consider the following sample code (test.cpp):
====
struct IA
{
    virtual ~IA() {}
};

struct IB
{
    virtual ~IB() {}
};

struct IC: virtual IA, virtual IB {};

struct CA : virtual IA {};

struct CB: virtual IB {};

struct CC: virtual IC, CA, CB {};

int main()
{
    CC c;
    return 0;
}
====
Compile it with g++ 4.9.1 (Debian sid amd64):
g++ -o test.asan -g -O0 -fno-omit-frame-pointer -fsanitize=address test.cpp
Running it gives the following report:

==3591==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff92d37da0 at pc 0x400f58 bp 0x7fff92d37d20 sp 0x7fff92d37d18
WRITE of size 16 at 0x7fff92d37da0 thread T0
    #0 0x400f57 in IC::~IC() test.cpp:11
    #1 0x401675 in CC::~CC() test.cpp:17
    #2 0x400a20 in main test.cpp:22
    #3 0x7fd0c55a6b44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
    #4 0x4008b8 (test.asan+0x4008b8)

Address 0x7fff92d37da0 is located in stack of thread T0 at offset 48 in frame
    #0 0x400995 in main test.cpp:20

  This frame has 1 object(s):
    [32, 56) 'c' <== Memory access at offset 48 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow test.cpp:11 IC::~IC()
Shadow bytes around the buggy address:
  0x10007259ef60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259ef70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259ef90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259efa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
=>0x10007259efb0: f1 f1 00 00[00]f4 f3 f3 f3 f3 00 00 00 00 00 00
  0x10007259efc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259efd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259efe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259eff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007259f000: 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
  Contiguous container OOB:fc
  ASan internal:           fe
==3591==ABORTING

When an object of type CC is allocated on heap the error is reported as well.
If an object of type CC is aggregated into another type and followed by another
field (e.g. the type of variable 'c' from the sample is
std::pair<CC,std::nullptr_t>) then the error no is reported.

No error is observed when clang++ 3.4.2 or g++ 4.8.3 is used.