From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-30371-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 15865 invoked by alias); 30 Nov 2007 08:58:22 -0000
Received: (qmail 15856 invoked by uid 22791); 30 Nov 2007 08:58:21 -0000
X-Spam-Check-By: sourceware.org
Received: from topsns2.toshiba-tops.co.jp (HELO topsns2.toshiba-tops.co.jp) (202.230.225.126)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Nov 2007 08:58:17 +0000
Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp           via smtpd (for sourceware.org [209.132.176.174]) with ESMTP; Fri, 30 Nov 2007 17:58:16 +0900
Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) 	by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 9759341C96; 	Fri, 30 Nov 2007 17:58:14 +0900 (JST)
Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) 	by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 8A4614179F; 	Fri, 30 Nov 2007 17:58:14 +0900 (JST)
Received: from localhost (fragile [172.17.28.65]) 	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id lAU8wEAF065620; 	Fri, 30 Nov 2007 17:58:14 +0900 (JST) 	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 30 Nov 2007 08:58:00 -0000
Message-Id: <20071130.175814.18313162.nemoto@toshiba-tops.co.jp>
To: gdb@sourceware.org
Subject: Re: gdbserver and "terminated with signal SIGTRAP"
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20071129.235502.95065374.anemo@mba.ocn.ne.jp>
References: <20071129.235502.95065374.anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-11/txt/msg00283.txt.bz2

On Thu, 29 Nov 2007 23:55:02 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> I confirmed that maybe_attach_thread() in thread-db.c did not call
> linux_attach_lwp() on the second time.  That was because
> find_inferior_id() returned non NULL value.  It seems
> find_inferior_id() returned the first thread (which should be dead
> before the second thread creation).

Now I understand why find_inferior_id() misbehaves.  The "id" is
actually pthread_t and it might be recycled.

For example, This program shows same id values!

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

void *func(void *data)
{
	return data;
}

int main(int argc, char **argv) 
{
        pthread_t id;
	int i;

	for (i = 0; i < 4; i++) {
		pthread_create(&id, NULL, func, NULL);
		printf("%x\n", id);
		pthread_join(id, NULL);
	}
	return 0;
}

$ ./foo
b7fdbb90
b7fdbb90
b7fdbb90
b7fdbb90


But... how can this be avoided?

---
Atsushi Nemoto