From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-32839-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10888 invoked by alias); 15 Aug 2008 18:26:32 -0000
Received: (qmail 10880 invoked by uid 22791); 15 Aug 2008 18:26:31 -0000
X-Spam-Check-By: sourceware.org
Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.113.40.141)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Aug 2008 18:25:48 +0000
Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.64.160]) 	by smtp-outbound-1.vmware.com (Postfix) with ESMTP id A51E1622B; 	Fri, 15 Aug 2008 11:25:45 -0700 (PDT)
Received: from [10.20.92.47] (promb-2s-dhcp47.eng.vmware.com [10.20.92.47]) 	by mailhost2.vmware.com (Postfix) with ESMTP id AFBA23C122; 	Fri, 15 Aug 2008 11:25:45 -0700 (PDT)
Message-ID: <48A5C9FF.4060403@vmware.com>
Date: Sat, 16 Aug 2008 08:47:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: Kari Nalli <kari880@gmail.com>
CC: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: gdb and muti threads with recvfrom
References: <568faa340808140255g6f00a83fl4661d015137fbdfc@mail.gmail.com> 	 <48A45D1B.6050609@vmware.com> <568faa340808150148o45a07ba6t889c2d6e218ee8b0@mail.gmail.com>
In-Reply-To: <568faa340808150148o45a07ba6t889c2d6e218ee8b0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
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: 2008-08/txt/msg00192.txt.bz2

Kari Nalli wrote:
> Hi,
>> 2008/8/14 Michael Snyder <msnyder@vmware.com>:
>> Something to do with signals and threads.
>> I think signals in one thread are not supposed to interrupt
>> other threads, but I'm not sure (and it may depend on the OS).
>>
>> Could be that one thread was waiting on a blocking system call,
>> and another thread took a SIGTRAP from a gdb breakpoint or
>> something...
> There where no breakpoints set in this case, can GDB generate signals
> for some reason?

Yes, gdb often sets its own breakpoints without bothering
to tell the user.  This is how shared library support is
implemented, for instance, as well as setjump/longjump support,
and potentially others.