From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22293 invoked by alias); 20 Feb 2006 18:20:10 -0000 Received: (qmail 22284 invoked by uid 22791); 20 Feb 2006 18:20:09 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Feb 2006 18:20:05 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k1KIK25B023402 for ; Mon, 20 Feb 2006 13:20:02 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k1KIK1110155; Mon, 20 Feb 2006 13:20:01 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k1KIJxjs011341; Mon, 20 Feb 2006 13:20:00 -0500 Message-ID: <43FA084F.4040407@redhat.com> Date: Mon, 20 Feb 2006 19:12:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Randolph Chung , gdb@sources.redhat.com Subject: Re: "run", and executable file/symtab association? References: <20060215030909.GB8700@nevyn.them.org> <43F6EEB4.4040002@tausq.org> <20060218152827.GA21241@nevyn.them.org> In-Reply-To: <20060218152827.GA21241@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00271.txt.bz2 Daniel Jacobowitz wrote: > On Sat, Feb 18, 2006 at 05:53:56PM +0800, Randolph Chung wrote: > >>>If kill_inferior calls pop_target it'd better be expecting to close a >>>native target, not the exec target further down the stack. This looks >>>like a bug in the checkpoint code somewhere. Ugh, the bits in >>>kill_inferior are a little scary. First thing to do: figure out what's >>>on the target stack (follow current_target.beneath), and why it's got >>>execution if it's popping exec_close. >> >>The target stack looks like: >> >>(top-gdb) print current_target->to_shortname >>$2 = 0x334298 "child" >>(top-gdb) print current_target->beneath->to_shortname >>$3 = 0x334298 "child" >>(top-gdb) print current_target->beneath->beneath->to_shortname >>$4 = 0x2d7d6c "exec" >>(top-gdb) print current_target->beneath->beneath->beneath->to_shortname >>$5 = 0x312614 "None" >> >>And to_close is: >>(top-gdb) print current_target->to_close >>$6 = (void (*)(int)) @0x38465a: 0x47954 > > pop_target calls current_target->to_close. I am suspecting that it > should call target_stack->to_close instead. > >>I don't pretend to understand this code and why if there are forks, we >>should be popping the target to kill everything. > > I don't either. Hey guys, Message received and acknowledged. I'm on vacation this week. Is it urgent? Michael