From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89624 invoked by alias); 3 May 2016 22:04:28 -0000 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 Received: (qmail 89615 invoked by uid 89); 3 May 2016 22:04:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:797 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 03 May 2016 22:04:27 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 209AE6F670; Tue, 3 May 2016 22:04:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u43M4Ods008410; Tue, 3 May 2016 18:04:25 -0400 Subject: Re: [PATCH] Add mi-threads-interrupt.exp test (PR 20039) To: Simon Marchi , gdb-patches@sourceware.org References: <1462305612-16493-1-git-send-email-simon.marchi@ericsson.com> <5983d4d2-016a-8020-c109-cb7ea2cfd179@redhat.com> From: Pedro Alves Message-ID: <47d2ec33-9e48-6046-47a2-544c7186de75@redhat.com> Date: Tue, 03 May 2016 22:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <5983d4d2-016a-8020-c109-cb7ea2cfd179@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00049.txt.bz2 On 05/03/2016 10:57 PM, Pedro Alves wrote: > I debugged this a little, and I see that the bug is that -exec-continue ends > up with thread 3 selected, which generates a =thread-selected event. Oh, BTW, I think this explains why reversing the thread list order exposed this bug. Before that patch, we'd issue an -exec-continue with thread 1 selected, and gdb would resume thread 3, thread 2, and thread 1, and thus end up with thread 1 selected again, and thus no =thread-selected event would be output. So I guess that if you select thread 2 before the -exec-continue, the test exposes the bug even before the thread list reordering patch. Might be good to do that in the test in case that detail ever changes again. Thanks, Pedro Alves