From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10993 invoked by alias); 12 Jan 2016 11:22:38 -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 10979 invoked by uid 89); 12 Jan 2016 11:22:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=forked, resets, preexisting, re-set 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, 12 Jan 2016 11:22:36 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 432496E786 for ; Tue, 12 Jan 2016 11:22:35 +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 u0CBMY5j002834; Tue, 12 Jan 2016 06:22:34 -0500 Message-ID: <5694E1F9.8070307@redhat.com> Date: Tue, 12 Jan 2016 11:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: Regression for gdb.threads/fork-plus-threads.exp [Re: [PATCH 3/6] List inferiors/threads/pspaces in ascending order] References: <1445507944-9197-1-git-send-email-palves@redhat.com> <1445507944-9197-4-git-send-email-palves@redhat.com> <20160108203938.GA24397@host1.jankratochvil.net> <5693BEBC.4020404@redhat.com> In-Reply-To: <5693BEBC.4020404@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-01/txt/msg00213.txt.bz2 On 01/11/2016 02:39 PM, Pedro Alves wrote: > On 01/08/2016 08:39 PM, Jan Kratochvil wrote: >> On Thu, 22 Oct 2015 11:59:01 +0200, Pedro Alves wrote: >> >> 7e0aa6aa9983c745aedc203db0cc360a0ad47cac is the first bad commit >> commit 7e0aa6aa9983c745aedc203db0cc360a0ad47cac >> Author: Pedro Alves >> Date: Tue Nov 24 18:11:21 2015 +0000 >> List inferiors/threads/pspaces in ascending order >> >> PASS->FAIL: >> FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: inferior 1 exited >> FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left (timeout) >> FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited) >> >> -PASS: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: inferior 1 exited >> +warning: Error removing breakpoint 1^M >> +Error in re-setting breakpoint 1: Warning:^M >> +Cannot insert breakpoint 1.^M >> +Cannot access memory at address 0x8048700^M >> +^M >> +Warning:^M >> +Cannot insert breakpoint 1.^M >> +Cannot access memory at address 0x8048700^M >> +^M >> +(gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: inferior 1 exited >> >> I haven't tried to debug it. >> >> It happens on Fedora 23 x86_64 with -m32 for the testsuite. > > I see it too on F20, and indeed only with -m32. I don't know why yet. This looks like just exposed a preexisting problem. When the second fork happens, we do a breakpoint reset, which wipes all locations and tries to recreate locations for inferior 2. Because that inferior is either running or exits and is now zombie, prologue skipping fails to read memory, and thus a breakpoint that used to be at line 64 (after prologue) ends up re-set to line 60 (before prologue). We then try to remove the old breakpoint at line 64 from inferior 2, which fails, because the inferior is either running or zombie. The reason we didn't see this before is that the code cache masked it. Before, we resumed the threads in the opposite order (newest first), and "luckily" the sequence of events in this particular test would be such that the code cache hasn't been flushed yet when we went to prologue skipping. "set code-cache off" makes the problem visible even before the patch. This doesn't trigger with native-extended-gdbserver/-m32 because gdbserver can read memory even when the inferior is running. This is also yet another instance of breakpoint re-setting being too coarse [1]... If inferior 1 forked inferior 3, why would we need to re-set breakpoint locations of inferior 2? I think we can avoid revamping breakpoint re-set completely, by instead limiting re-sets to the program space that triggered it. [1] - https://sourceware.org/gdb/wiki/BreakpointReset Thanks, Pedro Alves