From owner-freebsd-ports@FreeBSD.ORG Tue May 12 16:07:50 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13FD17E0; Tue, 12 May 2015 16:07:50 +0000 (UTC) Received: from mailrelay108.isp.belgacom.be (mailrelay108.isp.belgacom.be [195.238.20.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8881180; Tue, 12 May 2015 16:07:49 +0000 (UTC) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=M25fSHNwW0AVyF8PBjdaZiLQS1FBtLFJFIDkHdlBKq0= c=1 sm=2 a=kj9zAlcOel0A:10 a=4sMaG8rnAAAA:8 a=mDV3o1hIAAAA:8 a=QTjAbdG7XdtMy9zBsA4A:9 a=CjuIK1q_8ugA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BgBgB2I1JV//KPsFtcgw9UXscChgkCgTlNAQEBAQEBgQuEIQEBBCcTHCMQCxgJJQ8qHgYTCYgnAQjJUAEBAQEBAQEDAQEBAR6LOYJrghoHhC0BBJ03gSWDXpFoI4FmghM8MYJGAQEB Received: from 242.143-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.143.242]) by relay.skynet.be with ESMTP; 12 May 2015 18:06:38 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.9/8.14.9) with ESMTP id t4CG6cvK003306; Tue, 12 May 2015 18:06:38 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Tue, 12 May 2015 18:06:38 +0200 From: Tijl Coosemans To: Jason Woodward Cc: freebsd-ports@freebsd.org, jhb@FreeBSD.org Subject: Re: gdb in ports Message-ID: <20150512180638.6202c711@kalimero.tijl.coosemans.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 16:07:50 -0000 On Mon, 11 May 2015 16:21:42 -0400 Jason Woodward wrote: > Hi all, > > I had sent this to Luca but maybe others might have an idea... > > > I'm running into some difficulty debugging a live, multithreaded > application. This seems to be the case with the 7.8.x gdbs and 7.9 (both > 9.2 and 10 release). When I attach, I see duplicates for the first thread: > > 5 Thread 817ff2c00 (LWP 100541) 0x000000080bd6286c in poll () at > poll.S:3 > 4 Thread 80efe8c00 (LWP 100546) 0x000000080bd6286c in poll () at > poll.S:3 > 3 Thread 80efe9000 (LWP 100878) 0x000000080bd6286c in poll () at > poll.S:3 > * 2 Thread 80efe9400 (LWP 101124) 0x000000080bd6286c in poll () at > poll.S:3 > * 1 Thread 80efe9400 (LWP 101124) 0x000000080bd6286c in poll () at > poll.S:3 > > Trying to select 1 or 2 always ends up selecting 2: > > (gdb) thread 1 > [Switching to thread 2 (Thread 80efe9400 (LWP 101124))] > #0 0x000000080bd6286c in poll () at poll.S:3 > 3 in poll.S > (gdb) thread 2 > [Switching to thread 2 (Thread 80efe9400 (LWP 101124))] > #0 0x000000080bd6286c in poll () at poll.S:33 in poll.S > (gdb) > > On top of this, when stepping through it seems threads that start and stop > quickly have some sort of race condition that results in the thread > tracking getting messed up. Sometimes I'll end up on thread 74, other > times I will be on a thread that has gone away and "info threads" does not > show me associated with any of the active threads. With 7.8.x I would see: > > Id Target Id Frame > 75 Cannot find thread, Thread ID=101080, no thread to satisfy query > > > Unsure if related, but after stepping through with 7.9, the following > happens in fbsd_thread_wait(): > > infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion > `!tp->control.trap_expected' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) y > > This is a bug, please report it. For instructions, see: > . > > infrun.c:5530: internal-error: switch_back_to_stepped_thread: Assertion > `!tp->control.trap_expected' failed. > A problem internal to GDB has been detected,further debugging may prove > unreliable. > Create a core file of GDB? (y or n) n CC jhb. Maybe he can help.