public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: vwhite@entercept.com To: gcc-gnats@gcc.gnu.org Subject: libstdc++/8359: STL container can fault at runtime destroying contained objects with virtual destructors Date: Fri, 25 Oct 2002 13:06:00 -0000 [thread overview] Message-ID: <20021025200503.27226.qmail@sources.redhat.com> (raw) >Number: 8359 >Category: libstdc++ >Synopsis: STL container can fault at runtime destroying contained objects with virtual destructors >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Fri Oct 25 13:06:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Victor White, for D. Hosterman >Release: "gcc (GCC) 3.2 20020708 (experimental)" with "libstdc++-v3" >Organization: >Environment: HP PA2.0 hardware (compiling PA1.1 code), HP-UX 11i >Description: The standard template library file include/c++/3.2/bits/stl_construct.h includes a definition of the following template function: template <class _Tp> inline void _Destroy(_Tp* __pointer) { __pointer->~_Tp(); } The function will be called when destroying an element of a container (vector, list, etc.). If that element is a derived object with virtual destructors, it can end up calling an incorrect sequence of destructors which (on my system) results in a SIGSEGV when an object is removed from the container. >How-To-Repeat: Sorry, I don't happen to have a canned example. This appeared in a very large program we are working on which I have not included. Depends on the program. It must use a container that holds the object itself (not a pointer to). The object must be a derived type with a virtual destructor. >Fix: The change made locally was: template <class _Tp> inline void _Destroy(_Tp* __pointer) { __pointer->_Tp::~_Tp(); } //<= only our destructor Which seems to both make sense and fix the problem. We have not yet checked to see if there are other places in which destructors are being explicitly called that may have similar issues. >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2002-10-25 20:06 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-10-25 13:06 vwhite [this message] 2002-10-27 13:29 paolo 2002-10-28 11:16 Victor White 2002-10-31 9:21 bkoz 2002-11-01 8:39 bkoz 2002-11-19 12:26 bkoz
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20021025200503.27226.qmail@sources.redhat.com \ --to=vwhite@entercept.com \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).