From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26600 invoked by alias); 19 Dec 2011 09:32:17 -0000 Received: (qmail 26590 invoked by uid 22791); 19 Dec 2011 09:32:17 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Dec 2011 09:32:00 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pBJ9VbcF025169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 04:31:37 -0500 Received: from host2.jankratochvil.net (ovpn-116-60.ams2.redhat.com [10.36.116.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id pBJ9VV15021773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 19 Dec 2011 04:31:35 -0500 Date: Mon, 19 Dec 2011 09:54:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: gdb-patches@sourceware.org, Pedro Alves Subject: Re: [patch+7.4] reread.exp 7.3->7.4 regression Message-ID: <20111219093131.GA3484@host2.jankratochvil.net> References: <20111218115343.GB22534@host2.jankratochvil.net> <20111219034807.GN21915@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111219034807.GN21915@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2011-12/txt/msg00627.txt.bz2 Hi Joel, On Mon, 19 Dec 2011 04:48:07 +0100, Joel Brobecker wrote: > Unfortunately, I don't have an arm environment either. Perhaps > CodeSourcery does? OK, I will run it today. > Yeah, I'm a little concerned by your patch. It should go definitely also for the HEAD in such case until some other proper fix lands there, it is a memory data corruption. > Have we explored the idea of not registering the arm_exidx_data_free > routine? We'd leak some memory, The freeing is not the only problem. The same problem applies on the lines accessing the elements, those statements can also crash now without this patch. It is just not shown in this crash backtrace. Thanks, Jan