From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13055 invoked by alias); 12 Sep 2008 22:45:34 -0000 Received: (qmail 13036 invoked by uid 22791); 12 Sep 2008 22:45:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Sep 2008 22:44:57 +0000 Received: (qmail 9737 invoked from network); 12 Sep 2008 22:44:55 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Sep 2008 22:44:55 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix a crash on NULL event_thread Date: Fri, 12 Sep 2008 22:45:00 -0000 User-Agent: KMail/1.9.9 Cc: Jan Kratochvil References: <20080912221227.GA5848@host0.dyn.jankratochvil.net> In-Reply-To: <20080912221227.GA5848@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809122344.55797.pedro@codesourcery.com> 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: 2008-09/txt/msg00284.txt.bz2 Hi Jan, Sorry for the breakage. On Friday 12 September 2008 23:12:27, Jan Kratochvil wrote: > Hi Pedro, > > various testcases - such as gdb.threads/bp_in_thread.exp - crash HEAD. > Tested only on Fedora kernel-2.6.27-0.317.rc5.git10.fc10.x86_64 but I > expect it can happen anywhere. > > LINUX_HANDLE_EXTENDED_WAIT calls ADD_LWP but not ADD_THREAD. > > Found while investigating a bugreport from Shawn Starr. Hmm, it may be due to something having changed in the scheduling, as I'm on ubuntu's 2.6.24-19-generic x86_64 SMP (dual core), and I never saw that happen. I'd like to get rid of that ecs->new_thread_event, as you'll notice in handle_inferior_event just a bit below what you're changing, GDB will just resume that thread afterwards, meaning, the real event is just ignored. In this case, you'll get the breakpoint hit again, but we might lose something else... Plus, this new_thread_event is sometimes masking targets misbehaving --- we've tripped on that a few months ago. What I'd like to do, if possible, is to make sure that we never reach handle_inferior_event with a thread related event, for a thread that is not in the thread list. Would it be possible to add the thread to the thread list, in addition to the lwp? -- Pedro Alves