From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21688 invoked by alias); 23 Sep 2011 19:31:18 -0000 Received: (qmail 21675 invoked by uid 22791); 23 Sep 2011 19:31:17 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iy0-f169.google.com (HELO mail-iy0-f169.google.com) (209.85.210.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Sep 2011 19:31:03 +0000 Received: by iaen33 with SMTP id n33so5969164iae.0 for ; Fri, 23 Sep 2011 12:31:02 -0700 (PDT) Received: by 10.43.44.136 with SMTP id ug8mr4886689icb.143.1316806262538; Fri, 23 Sep 2011 12:31:02 -0700 (PDT) Received: from [172.31.110.167] ([64.238.244.146]) by mx.google.com with ESMTPS id r14sm16768808ibe.7.2011.09.23.12.30.59 (version=SSLv3 cipher=OTHER); Fri, 23 Sep 2011 12:31:00 -0700 (PDT) Subject: Re: Thread exit error : gdb7.2 in FreeBSD (built from ports) From: John Schumacher To: Pedro Alves Cc: gdb@sourceware.org In-Reply-To: References: <32463912.post@talk.nabble.com> <32503829.post@talk.nabble.com> <32503830.post@talk.nabble.com> <201109221811.16620.pedro@codesourcery.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 23 Sep 2011 19:31:00 -0000 Message-ID: <1316806255.1566.10.camel@johnUbuntu> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00108.txt.bz2 On Thu, 2011-09-22 at 17:06 -0500, John Schumacher wrote: > > This is very suspicious. Is FreeBSD calling into gdb twice for an > exiting thread? The first time, we are flagging it as exited, and > getting caught up in the get_current_frame() the second time? > > > Is fbsd-threads.c the one who is calling into gdb? Or how does that > relationship work? > Thanks again > -John > -- > John Schumacher > > I have questions about the following areas of code within fbsd-threads.c static ptid_t fbsd_thread_wait (struct target_ops *ops, ptid_t ptid, struct target_waitstatus *ourstatus, int options) { .... if (ourstatus->value.sig == TARGET_SIGNAL_TRAP) check_event(ret); /* this is a hack, if an event won't cause gdb to stop, for example, SIGARLM, gdb resumes the process immediatly without setting inferior_ptid to the new thread returned here, this is a bug because inferior_ptid may already not exist there, and passing a none existing thread to fbsd_thread_resume causes error. */ if (!fbsd_thread_alive (ops, inferior_ptid)) { delete_thread (inferior_ptid); inferior_ptid = ret; } } return (ret); } Don't we already notify gdb of this through handle_inferior_event? Why should fbsd-threads.c do this on its own? When debugging I saw the following: we remove the thread here, but later then an execution_control_state is still created for handle_inferior_event for the exiting lwp ( or thread, it's used ambiguously in the case of 1:1 threading) with stop_func_name = 0x8018c13c5 "_thread_bp_death" for the exiting thread. As the thread state is '_exiting', we will then get hosed later when we handle this as it checks get_current_frame() (which has an error if the thread state == exiting) and forces the user to have to switch to a different thread. When this delete is commented out, threads are still being properly removed and no error()'s are occurring. Can you shed any light on the condition that it is talking about? (Hopefully this message will pass through without modification, I'm using plain-text)