From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31755 invoked by alias); 28 Jan 2004 21:42:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31734 invoked from network); 28 Jan 2004 21:42:42 -0000 Received: from unknown (HELO relay2.EECS.Berkeley.EDU) (169.229.60.28) by sources.redhat.com with SMTP; 28 Jan 2004 21:42:42 -0000 Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0SLgfS2021940 for ; Wed, 28 Jan 2004 13:42:41 -0800 (PST) Received: from tully.CS.Berkeley.EDU (tully.CS.Berkeley.EDU [128.32.153.227]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0SLgekP002627; Wed, 28 Jan 2004 13:42:40 -0800 (PST) Received: from tully.CS.Berkeley.EDU (localhost [127.0.0.1]) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/3.141592645) with ESMTP id i0SLgeag018405; Wed, 28 Jan 2004 13:42:40 -0800 (PST) Received: from tully.CS.Berkeley.EDU (hilfingr@localhost) by tully.CS.Berkeley.EDU (8.12.7/8.12.7/Submit) with ESMTP id i0SLgdD6018402; Wed, 28 Jan 2004 13:42:39 -0800 (PST) Message-Id: <200401282142.i0SLgdD6018402@tully.CS.Berkeley.EDU> To: Andrew Cagney cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] breakpoint.c: Avoid double freeing in breakpoint_re_set_one In-Reply-To: Message from Andrew Cagney of "Wed, 28 Jan 2004 15:30:04 EST." <40181BCC.6050007@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18398.1075326159.1@tully.CS.Berkeley.EDU> Date: Wed, 28 Jan 2004 21:42:00 -0000 From: Paul Hilfinger X-SW-Source: 2004-01/txt/msg00726.txt.bz2 > > > # IDT/SIM apparently doesn't have enough file descriptors to allow the > > # problem checked by this test to occur. > > if [istarget "mips-idt-*"] { > > return 0; > > } > > is this true? If it is it looks more like a bug. Other workarounds may > be in the same situtation. Well, it's just a small modification of code I found strewn around other test cases that involved re-reading an executable and the like. If what you are saying is that GDB might be holding onto file descriptors too long, then I must agree, as indicated in a comment further down in the test: # Complication: Since GDB generally holds an open file descriptor on the # executable at this point, there are some systems in which the # re-compilation will fail.... That is, after the inferior exits, GDB (or, if you prefer, BFD) still has the executable file open (at least that's what it looked like to me). I'm curious as to whether this is an important feature. > Just check that the braces are indented: > > gdb_expect { > -re ... { > } > } OK Paul