c++/670: 2.91.66, 2.95.2 and 2.96 seem to call too many destructors.
sean.clarke@linux-software.clara.co.uk
sean.clarke@linux-software.clara.co.uk
Sun Oct 22 14:56:00 GMT 2000
>Number: 670
>Category: c++
>Synopsis: 2.91.66, 2.95.2 and 2.96 seem to call too many destructors.
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Oct 22 14:56:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Sean Clarke
>Release: Redhat 6.2 - 2.91.66, also detected in 2.95 and RH7 2.96 - gcc version 2.96 20000731
>Organization:
>Environment:
RedHat Linux 6.0, 6.1, 6.2, 7.0
>Description:
There appears to be a bug in gcc, can someone confirm ?. Attached is a
cpp file that demonstrates the problem which seems to cause the compiler
to call one (or more) too many destructors, we detected the problem
whilst porting an HP application to Linux and traced the core dumps etc.
to some code that wasn't too well written
(i.e. it was passing the object by value instead of by reference) anyway
it appears the compiler does something horrible, calls too many
destructors, and when we try to delete the object/use the object....
BANG.
>How-To-Repeat:
Just compile the attached program, you will see the counter value being output to sdout (increments and decrements when constructed or destructed).
you will see too many destructors being called.
>Fix:
no known fix, problem does not manifist itself if objects are always passed by reference (I think).
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="test.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.cpp"
I2luY2x1ZGUgPHV0aWxpdHk+CiNpbmNsdWRlIDxsaXN0PgojaW5jbHVkZSA8aW9zdHJlYW0+Cgpj
bGFzcyBDb3VudGVyCnsKcHVibGljOgoJQ291bnRlcigpOwoJfkNvdW50ZXIoKSB0aHJvdygpOwoJ
Q291bnRlciggY29uc3QgQ291bnRlciYgcmhzKTsKCglzdGF0aWMgaW50IGNvdW50KCkgeyByZXR1
cm4gY291bnRfOyB9CnByaXZhdGU6CglzdGF0aWMgaW50IGNvdW50XzsKCWludCBzdGF0ZTsKfTsK
CkNvdW50ZXI6OkNvdW50ZXIoKQp7CgkrK2NvdW50XzsKCWNvdXQgPDwgIkNvdW50ZXI6OkNvdW50
ZXIoKSBjb3VudF89IiA8PCBjb3VudF8gPDwgZW5kbDsKfQoKQ291bnRlcjo6fkNvdW50ZXIoKSB0
aHJvdygpCnsKCS0tY291bnRfOwoJY291dCA8PCAiQ291bnRlcjo6fkNvdW50ZXIoKSBjb3VudF89
IiA8PCBjb3VudF8gPDwgZW5kbDsKfQoKQ291bnRlcjo6Q291bnRlciggY29uc3QgQ291bnRlciYg
cmhzKQp7CgkrK2NvdW50XzsKCWNvdXQgPDwgIkNvdW50ZXI6OkNvdW50ZXIoKSBjb3VudF89IiA8
PCBjb3VudF8gPDwgZW5kbDsKfQoKaW50IENvdW50ZXI6OmNvdW50XyA9IDA7CgpjbGFzcyBSZXR1
cm5zX3BhaXIKewpwdWJsaWM6Cgl0eXBlZGVmIHBhaXI8IENvdW50ZXIsIENvdW50ZXIgPiBSZXR1
cm5zOwoKCVJldHVybnMgcGFpcigpIGNvbnN0Owp9OwoKUmV0dXJuc19wYWlyOjpSZXR1cm5zIFJl
dHVybnNfcGFpcjo6cGFpcigpIGNvbnN0CnsKCXJldHVybiBSZXR1cm5zKCk7Cn0KCmNsYXNzIEhv
bGRlcgp7CnB1YmxpYzoKCUhvbGRlciggQ291bnRlciBjb3VudGVyICkgOiBjb3VudGVyXyggY291
bnRlciApIHt9CnByaXZhdGU6CglDb3VudGVyIGNvdW50ZXJfOwp9OwoKaW50IG1haW4oKQp7Cglj
b3V0IDw8ICJJbiBtYWluIiA8PCBlbmRsOwoKCWxpc3Q8IEhvbGRlciA+IGxpc3Q7CgoJUmV0dXJu
c19wYWlyIHJldHVybnNfcGFpcjsKCglsaXN0LnB1c2hfYmFjayggSG9sZGVyKCByZXR1cm5zX3Bh
aXIucGFpcigpLmZpcnN0ICkgKTsKCgljb3V0IDw8IENvdW50ZXI6OmNvdW50KCkgPDwgIiBzaG91
bGQgYmUgMSIgPDwgZW5kbDsKCglyZXR1cm4gMDsKfQo=
More information about the Gcc-bugs
mailing list