[Bug c++/67557] New: Calling copy constructor of base class in constructor of derived class produces crashing code

["Georg.Baum at post dot rwth-aachen.de" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 67557
           Summary: Calling copy constructor of base class in constructor
                    of derived class produces crashing code
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Georg.Baum at post dot rwth-aachen.de
  Target Milestone: ---

Created attachment 36327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36327&action=edit
Test case

The bug reported below happens with a self compiled gcc on Linux (Debian
jessie):
$ LANG=C gcc-5.1 -v
Using built-in specs.
COLLECT_GCC=/home/u/bin-gcc5/bin/gcc-5.1
COLLECT_LTO_WRAPPER=/home/u/bin-gcc5/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.1.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5-branch/configure --prefix=/home/u/bin-gcc5
--program-suffix=-5.1 --enable-languages=c,c++,fortran --disable-bootstrap :
(reconfigured) ../gcc-5-branch/configure --prefix=/home/u/bin-gcc5
--program-suffix=-5.1 --enable-languages=c,c++,fortran --disable-bootstrap
Thread model: posix
gcc version 5.1.1 20150507 (GCC) 

Compiling and running the attached example with

g++-5.1 t.cpp -o t && ./t

produces an eror:

*** Error in `./t': free(): invalid pointer: 0x00007ffd93f3cae0 ***
Aborted.

Running the test case with valgrind produces this:

==6021== Memcheck, a memory error detector
==6021== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6021== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==6021== Command: ./t
==6021== 
==6021== Invalid free() / delete / delete[] / realloc()
==6021==    at 0x4C2A360: operator delete(void*) (vg_replace_malloc.c:507)
==6021==    by 0x4009E3: StartTag::~StartTag() (in /home/u/t)
==6021==    by 0x400A4B: FontTag::~FontTag() (in /home/u/t)
==6021==    by 0x400993: main (in /home/u/t)
==6021==  Address 0xffefffc80 is on thread 1's stack
==6021==  in frame #0, created by operator delete(void*)
(vg_replace_malloc.c:507)
==6021== 
==6021== 
==6021== HEAP SUMMARY:
==6021==     in use at exit: 72,704 bytes in 1 blocks
==6021==   total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==6021== 
==6021== LEAK SUMMARY:
==6021==    definitely lost: 0 bytes in 0 blocks
==6021==    indirectly lost: 0 bytes in 0 blocks
==6021==      possibly lost: 0 bytes in 0 blocks
==6021==    still reachable: 72,704 bytes in 1 blocks
==6021==         suppressed: 0 bytes in 0 blocks
==6021== Rerun with --leak-check=full to see details of leaked memory
==6021== 
==6021== For counts of detected and suppressed errors, rerun with: -v
==6021== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Compiling the same source with gcc 4.x produces a working executable. This bug
was originally reported as a LyX bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1260976. The code may not be
oprtimal (and I am going to change it in LyX to work around the compiler bug),
but it is valid.