From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9953 invoked by alias); 15 Jan 2008 22:20:05 -0000 Received: (qmail 9944 invoked by uid 22791); 15 Jan 2008 22:20:05 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 15 Jan 2008 22:19:38 +0000 Received: from kahikatea.snap.net.nz (226.62.255.123.dynamic.snap.net.nz [123.255.62.226]) by viper.snap.net.nz (Postfix) with ESMTP id E12113DA75E; Wed, 16 Jan 2008 11:19:35 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id B625B8FC6D; Wed, 16 Jan 2008 11:19:26 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18317.12654.364705.470631@kahikatea.snap.net.nz> Date: Tue, 15 Jan 2008 22:20:00 -0000 To: Aleksandar Ristovski Cc: gdb-patches@sourceware.org, Ryan Mansfield Subject: RE: [patch] Fix for varobj.c assertions. In-Reply-To: <2F6320727174C448A52CEB63D85D11F40AB0@nova.ott.qnx.com> References: <2F6320727174C448A52CEB63D85D11F40AB0@nova.ott.qnx.com> X-Mailer: VM 7.19 under Emacs 23.0.50.30 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00372.txt.bz2 > > Can anybody else duplicate this problem? (see pr2309) > > > > I did some more testing, it turns out it depends on the toolchain version. > > Toolchain that produced the problem: > gcc 4.1.1 > binutils 2.17 > > However, with > gcc 4.1.2 > binutils 2.18 > the problem does not reproduce. > > > The patch fixes the problem in the case of problematic toolchain version. Maybe it cures the symptom and not the cause. We really need to know what is happening here. In your oringinal report the failed assertion occurred in my_value_equal but that function has gone now. Presumably it now occurs in install_new_value, but at which line? When there is no problem, presumably *value (in adjust_value_for_child_access) or value (in c_describe_child) are null. How do they become non null for inaccessible memory in the failing case? -- Nick http://www.inet.net.nz/~nickrob