From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12689 invoked by alias); 5 Sep 2004 09:42:33 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 12679 invoked by uid 48); 5 Sep 2004 09:42:32 -0000 Date: Sun, 05 Sep 2004 09:42:00 -0000 Message-ID: <20040905094232.12678.qmail@sourceware.org> From: "caj at cs dot york dot ac dot uk" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040812195652.17012.debrak@sgi.com> References: <20040812195652.17012.debrak@sgi.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/17012] std::list's function, remove, looks like it is reading memory that has been freed. X-Bugzilla-Reason: CC X-SW-Source: 2004-09/txt/msg00410.txt.bz2 List-Id: ------- Additional Comments From caj at cs dot york dot ac dot uk 2004-09-05 09:42 ------- The cause of this problem is because list::remove takes the object to be searched for by reference. We then search along the list and (of course) remove it. This then means that any comparisions later on in the list are checking against a deleted variable, but tend to work because it was only just deleted. Strictly very bad things are happening here. This could be fixed by not taking the input by reference but instead taking a copy of it. This would however obviously be more inefficent. I think this problem in fact occurs in various places (basically whenever an function takes a series of iterators and an object, is it defined if that object obtained by dereferencing one of the inputer iterators?). I'm not sure that this is decided one way or the other generally, and probably should be. -- What |Removed |Added ---------------------------------------------------------------------------- CC| |caj at cs dot york dot ac | |dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012