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.
