From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7245 invoked by alias); 8 Nov 2012 15:51:11 -0000 Received: (qmail 7233 invoked by uid 22791); 8 Nov 2012 15:51:10 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,TW_TG X-Spam-Check-By: sourceware.org Received: from e06smtp10.uk.ibm.com (HELO e06smtp10.uk.ibm.com) (195.75.94.106) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Nov 2012 15:51:02 +0000 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 8 Nov 2012 15:51:00 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (9.149.109.196) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 8 Nov 2012 15:50:59 -0000 Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps4074.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qA8Foplx39714898 for ; Thu, 8 Nov 2012 15:50:51 GMT Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qA8F8j8A002951 for ; Thu, 8 Nov 2012 10:08:45 -0500 Received: from BR87Z6LW (dyn-9-152-212-247.boeblingen.de.ibm.com [9.152.212.247]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qA8F8iAB002920; Thu, 8 Nov 2012 10:08:44 -0500 From: Andreas Arnez To: jan.kratochvil@redhat.com, Pedro Alves Subject: Strange behavior of sigstep-threads.exp? CC: gdb@sourceware.org Date: Thu, 08 Nov 2012 15:51:00 -0000 Message-ID: <878vacnlem.fsf@linux.vnet.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii x-cbid: 12110815-4966-0000-0000-000004080CB9 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00005.txt.bz2 On x86-64 with upstream GDB, I'm observing what I consider strange behavior of the sigstep-threads.exp test case. Here's an excerpt from the log file: 32 var++; /* step-1 */ (gdb) disable $step1 (gdb) step Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. 33 tgkill (getpid (), gettid (), SIGUSR1); /* step-2 */ It seems that running from step-1 to step-2 produced four SIGUSR1. And in total ca. 3 times as many signals are encountered than we pass tgkill()'s: $ grep tgkill gdb.log | wc 100 1000 5900 $ grep 'Program received signal SIGUSR1' gdb.log | wc 310 2480 17670 >From the code I wouldn't expect that. Is this a known bug or expected behavior? Note that the test case doesn't fail, since it doesn't care about the number of incoming signals. On s390x the test case actually fails sometimes. In those cases, when stepping from step-1 to step-2, a ton of SIGUSR1 are indicated, and then the inferior seems to stop at the closing brace of the handler() function instead of the tgkill().