This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

c++/1627: overloading new[] and delete[] and what happens with fstream



>Number:         1627
>Category:       c++
>Synopsis:       overloading new[] and delete[] and what happens with fstream
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 11 21:56:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Steven Rostedt
>Release:        2.96  RedHat 7.0 version... Augh!
>Organization:
>Environment:
g++ -v -save-temps del.cc
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)
 /usr/lib/gcc-lib/i386-redhat-linux/2.96/cpp0 -lang-c++ -D__GNUG__=2 -v -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__tune_i386__ del.cc del.ii
GNU CPP version 2.96 20000731 (Red Hat Linux 7.0) (cpplib)
 (i386 Linux/ELF)
ignoring nonexistent directory "/usr/i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/g++-3
 /usr/local/include
 /usr/lib/gcc-lib/i386-redhat-linux/2.96/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i386-redhat-linux/2.96/cc1plus del.ii -quiet -dumpbase del.cc -version -o del.s
GNU C++ version 2.96 20000731 (Red Hat Linux 7.0) (i386-redhat-linux) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.0).
>Description:
I recently upgraded to RedHat 7.0, and I understand that
somethings RedHat did was funny. But this seems to be deeper
and it might be used in the later version of g++.

I overloaded new[] and delete[] as well as new and delete, 
but the problem is only with the [] memory operators.  And
in order to find memory leaks or free things that should not
I added a long word to the front of both, and used this
to test if memory is being used properly.  But when I started
using g++ 2.96, ifstream crashed on close.  It seems that
ifstream (and there may be others, but this is the only
one I came across) seems to use its own new[] but then
uses my overloaded delete[], which of course breaks.

I'm attaching a simple program that can show the problem.
>How-To-Repeat:
Using gcc version 2.96 20000731 (Red Hat Linux 7.0)
All I did was "g++ -Wall del.cc", also happens with -g option.
And run. It segfaults on the close of ifstream.
>Fix:
Seems that ifstream (or its parent fstreambase) needs to
either use both the new[] and delete[] that the user 
overloads, or use both from std.  I couldn't find the code
to do this, but I don't know where to look and I'm tired
and half a sleep right now.  Sorry.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="del.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="del.cc"

I2luY2x1ZGUgPGlvc3RyZWFtLmg+CiNpbmNsdWRlIDxmc3RyZWFtLmg+CiNpbmNsdWRlIDxzdGRs
aWIuaD4KCnZvaWQgKm9wZXJhdG9yIG5ld1tdIChzaXplX3Qgc2l6KQp7CiAgbG9uZyAqbCA9IChs
b25nKiltYWxsb2Moc2l6K3NpemVvZihsb25nKSk7CiAgbFswXSA9IDB4ZGVhZGJlZWY7CiAgcmV0
dXJuICh2b2lkKikobCsxKTsKfQoKdm9pZCBvcGVyYXRvciBkZWxldGVbXSAodm9pZCAqeCkKewog
IGxvbmcgKmwgPSAobG9uZyopeDsKICBsLS07CiAgaWYgKGxbMF0gIT0gKGxvbmcpMHhkZWFkYmVl
ZikgCiAgICBjZXJyIDw8ICJ3ZSBoYXZlIGEgcHJvYmxlbSBoZXJlISIgPDwgZW5kbDsKCiAgZnJl
ZSAobCk7Cn0KCgpjbGFzcyBibGFoIHsKcHJpdmF0ZToKICBpbnQgeDsKICBpbnQgeTsKcHVibGlj
OgogIGJsYWgoKSB7IHggPSAxOyB5ID0gMjsgfQogIH5ibGFoKCkgeyB9CgogIHZvaWQgc3ggKGlu
dCBhKSB7IHggPSBhOyB9CiAgdm9pZCBzeSAoaW50IGIpIHsgeSA9IGI7IH0KCiAgdm9pZCBwICh2
b2lkKSB7IGNvdXQgPDwgInggPSAiIDw8IHggPDwgZW5kbCA8PAoJCSAgICAieSA9ICIgPDwgeSA8
PCBlbmRsOyB9Cn07CgoKaW50IG1haW4gKGludCBhcmdjLCBjaGFyICoqYXJndikKewogIGlmc3Ry
ZWFtIGZzOwoKICBmcy5vcGVuKCIvZXRjL3Bhc3N3ZCIpOwogIGlmIChmcy5mYWlsKCkpIHsKICAg
IGNlcnIgPDwgIndoYXQgdGhlPz8iIDw8IGVuZGw7CiAgICBleGl0ICgwKTsKICB9IC8vIGVuZGlm
CgogIHdoaWxlICghZnMuZW9mKCkpIHsKCiAgICBjaGFyIGNoOwoKICAgIGZzLmdldChjaCk7Cgoj
aWYgMQogICAgaWYgKGNoID09ICdcbicpIHsKICAgICAgLy8gZG8gc29tZSBjcmF6eSBhcnJheXMu
CiAgICAgIGJsYWggKmI7CiAgICAgIAogICAgICBiID0gbmV3IGJsYWhbMjNdOwogICAgICAKICAg
ICAgZm9yIChpbnQgaT0wOyBpIDwgMjM7IGkrKykgCgliW2ldLnAoKTsKICAgIH0KI2VuZGlmCiAg
fSAvLyBlbmR3aGlsZQoKICBmcy5jbG9zZSgpOwp9CiAgCiAgCiAgCg==

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]