From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23956 invoked by alias); 23 Jan 2015 12:29:24 -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 23895 invoked by uid 89); 23 Jan 2015 12:29:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: mail-pd0-f181.google.com Received: from mail-pd0-f181.google.com (HELO mail-pd0-f181.google.com) (209.85.192.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 23 Jan 2015 12:29:15 +0000 Received: by mail-pd0-f181.google.com with SMTP id g10so5757545pdj.12 for ; Fri, 23 Jan 2015 04:29:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EBB+4qOs2IQdIsnpHTQ91Gowmko5MSUW1g1B1bjs0vU=; b=m6g5k1RHvA4/kraN1CHxMerSltg8ca+LXnQE2ZuvN69QAKa4wvXe4tw50XD3B4dOUa tB4ajWCO0rgJKpA80ASUY/tqFnOlyfVLFb3vDCifI7Bw9fT4TYGDsoGT0DWUromfAKqO QmQz+JQSMRaIVTDokzO26TI33awBKcxnEukqhjq0U+gjkYBAiFTAi0mfCoHhEUOCkLLT z0vNqk1akAwjCDc+iyOM1xp/qiXqAcaju+LvVnFiBcZvfEGeey2l3U7dQ8JNGaCvi1Cp W3yCgyspJrb6IuAeE6mTV/bgON6eh9fQ1vjXqr4D4PwWily5G/VJoYvFzRgSI6+Zp+R8 4uHg== X-Gm-Message-State: ALoCoQndtTYUXZieIhCb/VwVAO7g0S8ixakCdvHhUYVTl49tXqitet2IgYRJ0cwlgDmJ5JPwv9tv X-Received: by 10.66.120.201 with SMTP id le9mr10846589pab.124.1422016153147; Fri, 23 Jan 2015 04:29:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.70.22.145 with HTTP; Fri, 23 Jan 2015 04:28:52 -0800 (PST) In-Reply-To: References: <1389686678-9039-1-git-send-email-markus.t.metzger@intel.com> <1389686678-9039-7-git-send-email-markus.t.metzger@intel.com> <20150108204943.GA4851@host2.jankratochvil.net> From: Patrick Palka Date: Fri, 23 Jan 2015 12:55:00 -0000 Message-ID: Subject: Re: x86_64-m32 internal error for multi-thread-step.exp [Re: [PATCH v10 06/28] btrace: change branch trace data structure] To: "Metzger, Markus T" Cc: Jan Kratochvil , "palves@redhat.com" , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-01/txt/msg00647.txt.bz2 On Thu, Jan 22, 2015 at 7:29 AM, Metzger, Markus T wrote: >> -----Original Message----- >> From: Metzger, Markus T >> Sent: Tuesday, January 20, 2015 4:08 PM >> To: Jan Kratochvil >> Cc: palves@redhat.com; gdb-patches@sourceware.org > > >> I can't reproduce this fail; I don't get that far. This test fails for me with >> >> FAIL: gdb.btrace/multi-thread-step.exp: continue to breakpoint: cont >> to multi-thread-step.c:34 (timeout) > > This fail seems to be caused by 588dcc3edbde19f90e76de969dbfa7ab3e17951a > "Consolidate the custom TUI query hook with the default query hook". It is not > related to btrace. > > The failing test program looks like this: > > pthread_barrier_wait (&barrier); > global = 42; /* bp.1 */ > pthread_barrier_wait (&barrier); > > There are two threads, both are at bp.1 between the two barriers. When I now > delete all breakpoints like this: > > (gdb) del > Delete all breakpoints? (y or n) y > > and then continue the inferior, only the current thread is resumed. The other > thread remains at its current location. The resumed thread waits at the barrier > and the test runs into a timeout. > > Here's a complete debug session: > > (gdb) b 30 > Breakpoint 1 at 0x400776: file gdb.btrace/multi-thread-step.c, line 30. > (gdb) r > Starting program: gdb.btrace/multi-thread-step > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > [New Thread 0x7ffff7fce700 (LWP 22156)] > > Breakpoint 1, test (arg=0x0) at gdb.btrace/multi-thread-step.c:30 > 30 global = 42; /* bp.1 */ > (gdb) del > Delete all breakpoints? (y or n) y > (gdb) info thr > Id Target Id Frame > 2 Thread 0x7ffff7fce700 (LWP 22156) "multi-thread-st" test (arg=0x0) at gdb.btrace/multi-thread-step.c:30 > * 1 Thread 0x7ffff7fcf740 (LWP 22152) "multi-thread-st" test (arg=0x0) at gdb.btrace/multi-thread-step.c:30 > (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x000000384380c20c in pthread_barrier_wait () from /lib64/libpthread.so.0 > (gdb) info thr > Id Target Id Frame > 2 Thread 0x7ffff7fce700 (LWP 22156) "multi-thread-st" test (arg=0x0) at gdb.btrace/multi-thread-step.c:30 > * 1 Thread 0x7ffff7fcf740 (LWP 22152) "multi-thread-st" 0x000000384380c20c in pthread_barrier_wait () from /lib64/libpthread.so.0 > > When I set debug infrun, I get the this: > > (gdb) del > Delete all breakpoints? (y or n) y > (gdb) > infrun: target_wait (-1, status) = > infrun: -1 [process -1], > infrun: status->kind = no-resumed > infrun: TARGET_WAITKIND_NO_RESUMED (ignoring) > infrun: prepare_to_wait > > I don't see this with the old query behaviour or when I remove breakpoints like this > > (gdb) del 1 Sorry for the breakage. I had noticed that multi-thread-step.exp sometimes fails but I did not realize the non-deterministic failure was introduced by my patch. I thought it was a preexisting failure, but of course I should have empirically confirmed this belief. > > regards, > markus. > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk > Registergericht: Muenchen HRB 47456 > Ust.-IdNr./VAT Registration No.: DE129385895 > Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >