Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org,
	Sergio Durigan Junior <sergiodj@redhat.com>,
	Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH] Fix batch exit status test failure on Fedora 28
Date: Tue, 04 Sep 2018 14:37:00 -0000	[thread overview]
Message-ID: <20180904143726.GA24733@blade.nx> (raw)
In-Reply-To: <0c814c97-fb8c-f2ff-1e1e-02d8fcebd509@redhat.com>

Pedro Alves wrote:
> On 09/03/2018 05:12 PM, Gary Benson wrote:
> > Pedro Alves <palves@redhat.com> wrote:
> > > Yeah, if we compare with gdb.base/quit.exp, that is missing
> > > as well as the "remote_close host" call.  For the latter, when I last
> > > touched quit.exp, I remember fretting a bit about whether the remote_close
> > > was really necessary, but in the end decided to keep it, I don't recall
> > > exactly if I kept it because I found it's necessary (probably for
> > > remote hosts), or because it doesn't hurt.
> > >
> > > Now that I look at gdb.base/quit.exp again, I see that
> > > gdb.base/batch-exit-status.exp can hang forever in the same way that
> > > 15763a09d4ae fixed, isn't it?  Gary, any reason you didn't do the
> > > "eof" thing here too?
> > 
> > I didn't realize what it did; I thought it was something specific to
> > that test.  And I thought the gdb_exit at the start of the test would
> > clear $gdb_spawn_id but apparently not! :)  So I made a fix, basically
> > copied and pasted from the commit you referenced:
> > 
> > This commit changes the batch exit status test to detect GDB's exit
> > using gdb_test_multiple expecting 'eof', instead of using 'wait'.
> 
> > This fixes failures reported by buildbot on Fedora 28, and also means
> 
> Please expand here what the failure was, for the logs.  Something concise
> mentioning gdb_spawn_id, doesn't have to be long.  It just should be more
> self contained so that someone reading back the logs later on understands
> what it was.
> 
> > the testcase won't hang forever on failure as fixed in
> > gdb.base/quit.exp by commit 15763a09d4aea85fc3153d6746c040dd48565637.
> 
> Please write the commit in Linux-commit-style:
> 
> commit 15763a09d4ae ("Fix 'gdb.base/quit.exp hangs forever' if
> the test fails").
> 
> to help the human reading the logs.

I've pushed the patch with the following message:

  Fix batch exit status test failure on Fedora 28
  
  This commit adds calls to remote_close and clear_gdb_spawn_id to
  gdb.base/batch-exit-status.exp, fixing failures reported by buildbot
  on Fedora 28 where gdb_spawn_id not being reset by the previous test
  caused default_gdb_spawn to return without spawning.
  
  This commit also changes the test to use detect GDB's exit using
  gdb_test_multiple expecting 'eof', rather than using 'wait -i' alone.
  This means the testcase won't hang forever on failure as fixed in
  gdb.base/quit.exp by commit 15763a09d4ae ("Fix 'gdb.base/quit.exp
  hangs forever' if the test fails").
  
  gdb/testsuite/ChangeLog:

        * gdb.base/batch-exit-status.exp: Use gdb_test_multiple and expect
        'eof' before 'wait -i'.  Use remote_close and clear_gdb_spawn_id.

Thanks,
Gary


  reply	other threads:[~2018-09-04 14:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22 10:47 [PATCH v2] Indicate batch mode failures by exiting with nonzero status Gary Benson
2018-08-22 14:37 ` Eli Zaretskii
2018-08-23  8:00   ` Gary Benson
2018-08-23 16:37 ` Pedro Alves
2018-08-30 20:26 ` Sergio Durigan Junior
2018-08-31 13:30   ` Gary Benson
2018-08-31 14:33     ` Tom Tromey
2018-08-31 14:42       ` Pedro Alves
2018-09-03 16:12         ` [PATCH] Fix batch exit status test failure on Fedora 28 Gary Benson
2018-09-04 11:39           ` Pedro Alves
2018-09-04 14:37             ` Gary Benson [this message]
2018-08-31 15:38     ` [PATCH v2] Indicate batch mode failures by exiting with nonzero status Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180904143726.GA24733@blade.nx \
    --to=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=sergiodj@redhat.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox