From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17787 invoked by alias); 23 Jun 2015 19:03:18 -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 17769 invoked by uid 89); 23 Jun 2015 19:03:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 23 Jun 2015 19:03:07 +0000 Received: by oigb199 with SMTP id b199so14049224oig.3 for ; Tue, 23 Jun 2015 12:03:05 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=DfjGN2HbKCJt8gu4Sy9fV0fiPt0brl/f+gSqBaeDSCg=; b=URGyOu/pfZIzWGeq5KhaSwotlky/lc8MYgeq0F7sDn0dZWu1/PmfiYJIku5wsebwJP Q7cmh+99GXt6JPDeGbe0JzmYwhVK3hD6R1vEu0FZtmErMCbzJnJNCqtq7c+JevvktBMl iSaZObHxZb1LitZl93plm7HiTP4tF2V22nMmBD/Z4NrSv467EEuofbFnAuEZGBJNXyA4 vQfg7Fn4ZjIh+kv28nvI5olR5HOReut6Bla9wbJx9GVXze8/B1HdW+/8Ag1Zf5Teh2at T2g4opvSzyfAiAspPmsuJj39NlvwFolkWsJYundvAgA/0MnNUIraHDrXqBQAtNn/MhHk xSCw== X-Gm-Message-State: ALoCoQlYW5Nsdgo6GZokvBtrDha6OVKYGf8ICfhWIxLoIeDQgeDlVXuOxJfuRSOXyUkFI/bBC/qR MIME-Version: 1.0 X-Received: by 10.202.80.204 with SMTP id e195mr29589806oib.116.1435086185708; Tue, 23 Jun 2015 12:03:05 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Tue, 23 Jun 2015 12:03:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jun 2015 19:03:00 -0000 Message-ID: Subject: Re: Several regressions and we branch soon. From: Doug Evans To: Patrick Palka Cc: Joel Brobecker , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00500.txt.bz2 On Tue, Jun 23, 2015 at 1:55 PM, Patrick Palka wrote: > On Tue, Jun 23, 2015 at 2:31 PM, Doug Evans wrote: >> Hi. >> >> fyi, I'm seeing regressions in the following tests on amd64-linux. >> >> FAIL: gdb.threads/attach-stopped.exp: nonthreaded: attach2 to stopped bt >> FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt >> FAIL: gdb.base/attach-pie-noexec.exp: attach >> FAIL: gdb.base/attach-pie-noexec.exp: info shared >> FAIL: gdb.base/attach-twice.exp: attach >> FAIL: gdb.base/attach.exp: attach1, after setting file >> FAIL: gdb.base/attach.exp: attach1 detach (the program is no longer running) >> FAIL: gdb.base/attach.exp: attach2, with no file >> FAIL: gdb.base/attach.exp: after attach2, set should_exit >> FAIL: gdb.base/attach.exp: continue to breakpoint: postloop (the >> program is no longer running) >> FAIL: gdb.base/attach.exp: continue until exit at after attach2, exit >> (the program is no longer running) >> FAIL: gdb.base/attach.exp: attach when process' a.out not in cwd >> FAIL: gdb.base/attach.exp: continue until exit (the program is no >> longer running) >> FAIL: gdb.base/attach.exp: starting with --pid (timeout) >> FAIL: gdb.base/attach.exp: cmdline attach run: run to prompt >> UNRESOLVED: gdb.base/attach.exp: cmdline attach run: run to main >> FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugNO: >> BINprelinkNOdebugNOpieNO: attach: attach main bt >> FAIL: gdb.base/break-interp.exp: LDprelinkNOdebugNO: >> BINprelinkNOdebugNOpieYES: attach: seen displacement message as >> NONZERO >> ... plus lots more for break-interp.exp ... >> FAIL: gdb.base/default.exp: info set >> FAIL: gdb.base/default.exp: show >> FAIL: gdb.base/dprintf-detach.exp: bai=on ds=gdb dd=on: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=on ds=gdb dd=off: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=on ds=call dd=on: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=on ds=call dd=off: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=on ds=agent dd=on: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=on ds=agent dd=off: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=off ds=gdb dd=on: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=off ds=gdb dd=off: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=off ds=call dd=on: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=off ds=call dd=off: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=off ds=agent dd=on: re-attach to inferior >> FAIL: gdb.base/dprintf-detach.exp: bai=off ds=agent dd=off: re-attach >> to inferior >> FAIL: gdb.base/gnu_vector.exp: call add_singlevecs >> FAIL: gdb.base/gnu_vector.exp: continue to add_some_intvecs >> FAIL: gdb.base/gnu_vector.exp: continue to add_some_intvecs (the >> program is no longer running) >> FAIL: gdb.base/gnu_vector.exp: set vector return value >> FAIL: gdb.multi/multi-attach.exp: backtrace 1 >> FAIL: gdb.multi/multi-attach.exp: backtrace 2 >> FAIL: gdb.python/py-sync-interp.exp: attach and where >> FAIL: gdb.server/ext-attach.exp: backtrace 1 >> FAIL: gdb.server/ext-attach.exp: detach (the program is no longer running) >> FAIL: gdb.server/ext-attach.exp: backtrace 2 >> FAIL: gdb.server/ext-attach.exp: monitor exit >> FAIL: gdb.threads/attach-into-signal.exp: nonthreaded: detach (the >> program is no longer running) >> UNRESOLVED: gdb.threads/attach-into-signal.exp: nonthreaded: attach >> (pass 1), pending signal catch >> FAIL: gdb.threads/attach-into-signal.exp: threaded: thread apply 2 >> print $_siginfo.si_signo >> FAIL: gdb.threads/attach-into-signal.exp: threaded: detach (the >> program is no longer running) >> UNRESOLVED: gdb.threads/attach-into-signal.exp: threaded: attach (pass >> 1), pending signal catch >> >> I haven't root-caused any of them yet. >> Is anyone else seeing these on amd64-linux? > > GDB has not been clean of FAILs for a while right? IIRC I've been > seeing dozens of FAILs since I started submitting patches to GDB > (around June 2014). So I wonder how many of these are long-standing > FAILs not introduced in this development cycle. GDB has not been clean "since forever". However, my testing harness takes that into account. I have lists of tests I expect to see fail for each of my test configs (fission, no-fission, and so on), and my harness post-processes gdb.sum to produce a better report of pass/fail. (using a version of validate_failures.py from gcc) When something shows up that I haven't seen before, and I run these tests A LOT, I can tell. Every one of the above is new(ish - at least new in the last few months - I've been sidelined for a few reasons and haven't been running the tests as often as I normally do).