From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22426 invoked by alias); 29 Jun 2009 21:35:47 -0000 Received: (qmail 22417 invoked by uid 22791); 29 Jun 2009 21:35:45 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 21:35:38 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n5TLXaZw018456; Mon, 29 Jun 2009 17:33:36 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n5TLXZnn029586; Mon, 29 Jun 2009 17:33:36 -0400 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n5TLXYcs027699; Mon, 29 Jun 2009 17:33:35 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n5TLXXJa008664; Mon, 29 Jun 2009 23:33:33 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.3/Submit) id n5TLXXBE008663; Mon, 29 Jun 2009 23:33:33 +0200 Date: Mon, 29 Jun 2009 21:35:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix internal-error on dead LWPs with no associated thread Message-ID: <20090629213333.GA3295@host0.dyn.jankratochvil.net> References: <20090629100922.GA26882@host0.dyn.jankratochvil.net> <20090629174929.GA9652@host0.dyn.jankratochvil.net> <20090629182852.GA14913@host0.dyn.jankratochvil.net> <200906291941.52129.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906291941.52129.pedro@codesourcery.com> User-Agent: Mutt/1.5.19 (2009-01-05) 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: 2009-06/txt/msg00851.txt.bz2 On Mon, 29 Jun 2009 20:41:51 +0200, Pedro Alves wrote: > 1 - I'm not convinced currently that adding threads immediately to the list in > all-stop mode in linux_handle_extended_wait is a good idea. See here for > thoughts around that: > > http://sourceware.org/ml/gdb/2009-05/msg00067.html I do not share this opinion - not attaching short-lived threads should not be allowed for performance reasons. When such short-lived thread crashes GDB should catch such crash. > 2 - If the target has let the thread escape this far without having added it to > the list, *and* the target needs to book-keep extra thread info associated > with the thread structure, than your patch looks like paparing over a bug. > It's just a simple to handle it in the target's target_wait implementation, > just before returning an event. > > 3 - I really just meant to just remove this whole block: > > - if (ecs->new_thread_event) > - { > - if (non_stop) > - /* Non-stop assumes that the target handles adding new threads > - to the thread list. */ > - internal_error (__FILE__, __LINE__, "\ > -targets should add new threads to the thread list themselves in non-stop mode."); > - > - /* We may want to consider not doing a resume here in order to > - give the user a chance to play with the new thread. It might > - be good to make that a user-settable option. */ > - > - /* At this point, all threads are stopped (happens automatically > - in either the OS or the native code). Therefore we need to > - continue all threads in order to make progress. */ > - > - if (!ptid_equal (ecs->ptid, inferior_ptid)) > - context_switch (ecs->ptid); > - target_resume (RESUME_ALL, 0, TARGET_SIGNAL_0); > - prepare_to_wait (ecs); > - return; > - } Such a review for myself why: On GNU/Linux if linux_test_for_tracefork() fails then the new LWP is left unstopped - so it needs no target_resume. On GNU/Linux if linux_test_for_tracefork() succeeds then the new LWP is left unstopped immediately after catching its clone event by linux_handle_extended_wait as it is called with STOPPING 0. So no target_resume is needed. For other OSes expectin no one stops the new LWP. (I currently do not have an opinion on this removal, it is just a dead code.) Thanks, Jan