public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH v2] Indicate batch mode failures by exiting with nonzero status
@ 2018-08-22 10:47 Gary Benson
  2018-08-22 14:37 ` Eli Zaretskii
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Gary Benson @ 2018-08-22 10:47 UTC (permalink / raw)
  To: gdb-patches; +Cc: tom

Hi all,

This patch causes GDB in batch mode to exit with nonzero status
if the last command to be executed fails.

Changes since version 1:
 - I've reworked the patch to not use a global variable.
 - Behaviour has not changed from version 1.

Built and regtested on RHEL 7.5 x86_64.

Ok to commit?

Thanks,
Gary

--
gdb/ChangeLog:

	PR gdb/13000:
	* gdb/main.c (captured_main_1): Exit with nonzero status
	in batch mode if the last command to be executed failed.
	* NEWS: Mention the above.

gdb/testsuite/ChangeLog:

	PR gdb/13000:
	* gdb.base/batch-exit-status.exp: New file.
	* gdb.base/batch-exit-status.good-commands: Likewise.
	* gdb.base/batch-exit-status.bad-commands: Likewise.
---
 gdb/ChangeLog                                      |  7 ++
 gdb/NEWS                                           |  3 +
 gdb/main.c                                         | 78 +++++++++++++---------
 gdb/testsuite/ChangeLog                            |  7 ++
 .../gdb.base/batch-exit-status.bad-commands        |  1 +
 gdb/testsuite/gdb.base/batch-exit-status.exp       | 63 +++++++++++++++++
 .../gdb.base/batch-exit-status.good-commands       |  1 +
 7 files changed, 129 insertions(+), 31 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/batch-exit-status.bad-commands
 create mode 100644 gdb/testsuite/gdb.base/batch-exit-status.exp
 create mode 100644 gdb/testsuite/gdb.base/batch-exit-status.good-commands

diff --git a/gdb/NEWS b/gdb/NEWS
index 16d3d72..6af712a 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -10,6 +10,9 @@
 * DWARF index cache: GDB can now automatically save indices of DWARF
   symbols on disk to speed up further loading of the same binaries.
 
+* GDB in batch mode now exits with status 1 if the last command to be
+  executed failed.
+
 * New commands
 
 frame apply [all | COUNT | -COUNT | level LEVEL...] [FLAG]... COMMAND
diff --git a/gdb/main.c b/gdb/main.c
index e925128..61644cd 100644
--- a/gdb/main.c
+++ b/gdb/main.c
@@ -486,6 +486,7 @@ captured_main_1 (struct captured_main_args *context)
   int i;
   int save_auto_load;
   struct objfile *objfile;
+  int ret = 1;
 
 #ifdef HAVE_USEFUL_SBRK
   /* Set this before constructing scoped_command_stats.  */
@@ -986,7 +987,7 @@ captured_main_1 (struct captured_main_args *context)
      processed; it sets global parameters, which are independent of
      what file you are debugging or what directory you are in.  */
   if (system_gdbinit && !inhibit_gdbinit)
-    catch_command_errors (source_script, system_gdbinit, 0);
+    ret = catch_command_errors (source_script, system_gdbinit, 0);
 
   /* Read and execute $HOME/.gdbinit file, if it exists.  This is done
      *before* all the command line arguments are processed; it sets
@@ -994,7 +995,7 @@ captured_main_1 (struct captured_main_args *context)
      debugging or what directory you are in.  */
 
   if (home_gdbinit && !inhibit_gdbinit && !inhibit_home_gdbinit)
-    catch_command_errors (source_script, home_gdbinit, 0);
+    ret = catch_command_errors (source_script, home_gdbinit, 0);
 
   /* Process '-ix' and '-iex' options early.  */
   for (i = 0; i < cmdarg_vec.size (); i++)
@@ -1004,12 +1005,12 @@ captured_main_1 (struct captured_main_args *context)
       switch (cmdarg_p.type)
 	{
 	case CMDARG_INIT_FILE:
-	  catch_command_errors (source_script, cmdarg_p.string,
-				!batch_flag);
+	  ret = catch_command_errors (source_script, cmdarg_p.string,
+				      !batch_flag);
 	  break;
 	case CMDARG_INIT_COMMAND:
-	  catch_command_errors (execute_command, cmdarg_p.string,
-				!batch_flag);
+	  ret = catch_command_errors (execute_command, cmdarg_p.string,
+				      !batch_flag);
 	  break;
 	}
     }
@@ -1017,11 +1018,11 @@ captured_main_1 (struct captured_main_args *context)
   /* Now perform all the actions indicated by the arguments.  */
   if (cdarg != NULL)
     {
-      catch_command_errors (cd_command, cdarg, 0);
+      ret = catch_command_errors (cd_command, cdarg, 0);
     }
 
   for (i = 0; i < dirarg.size (); i++)
-    catch_command_errors (directory_switch, dirarg[i], 0);
+    ret = catch_command_errors (directory_switch, dirarg[i], 0);
 
   /* Skip auto-loading section-specified scripts until we've sourced
      local_gdbinit (which is often used to augment the source search
@@ -1036,19 +1037,20 @@ captured_main_1 (struct captured_main_args *context)
       /* The exec file and the symbol-file are the same.  If we can't
          open it, better only print one error message.
          catch_command_errors returns non-zero on success!  */
-      if (catch_command_errors (exec_file_attach, execarg,
-				!batch_flag))
-	catch_command_errors (symbol_file_add_main_adapter, symarg,
-			      !batch_flag);
+      ret = catch_command_errors (exec_file_attach, execarg,
+				  !batch_flag);
+      if (ret != 0)
+	ret = catch_command_errors (symbol_file_add_main_adapter,
+				    symarg, !batch_flag);
     }
   else
     {
       if (execarg != NULL)
-	catch_command_errors (exec_file_attach, execarg,
-			      !batch_flag);
+	ret = catch_command_errors (exec_file_attach, execarg,
+				    !batch_flag);
       if (symarg != NULL)
-	catch_command_errors (symbol_file_add_main_adapter, symarg,
-			      !batch_flag);
+	ret = catch_command_errors (symbol_file_add_main_adapter,
+				    symarg, !batch_flag);
     }
 
   if (corearg && pidarg)
@@ -1056,9 +1058,14 @@ captured_main_1 (struct captured_main_args *context)
 	     "a core file at the same time."));
 
   if (corearg != NULL)
-    catch_command_errors (core_file_command, corearg, !batch_flag);
+    {
+      ret = catch_command_errors (core_file_command, corearg,
+				  !batch_flag);
+    }
   else if (pidarg != NULL)
-    catch_command_errors (attach_command, pidarg, !batch_flag);
+    {
+      ret = catch_command_errors (attach_command, pidarg, !batch_flag);
+    }
   else if (pid_or_core_arg)
     {
       /* The user specified 'gdb program pid' or gdb program core'.
@@ -1067,14 +1074,20 @@ captured_main_1 (struct captured_main_args *context)
 
       if (isdigit (pid_or_core_arg[0]))
 	{
-	  if (catch_command_errors (attach_command, pid_or_core_arg,
-				    !batch_flag) == 0)
-	    catch_command_errors (core_file_command, pid_or_core_arg,
-				  !batch_flag);
+	  ret = catch_command_errors (attach_command, pid_or_core_arg,
+				      !batch_flag);
+	  if (ret == 0)
+	    ret = catch_command_errors (core_file_command,
+					pid_or_core_arg,
+					!batch_flag);
+	}
+      else
+	{
+	  /* Can't be a pid, better be a corefile.  */
+	  ret = catch_command_errors (core_file_command,
+				      pid_or_core_arg,
+				      !batch_flag);
 	}
-      else /* Can't be a pid, better be a corefile.  */
-	catch_command_errors (core_file_command, pid_or_core_arg,
-			      !batch_flag);
     }
 
   if (ttyarg != NULL)
@@ -1098,7 +1111,7 @@ captured_main_1 (struct captured_main_args *context)
 	{
 	  auto_load_local_gdbinit_loaded = 1;
 
-	  catch_command_errors (source_script, local_gdbinit, 0);
+	  ret = catch_command_errors (source_script, local_gdbinit, 0);
 	}
     }
 
@@ -1118,12 +1131,12 @@ captured_main_1 (struct captured_main_args *context)
       switch (cmdarg_p.type)
 	{
 	case CMDARG_FILE:
-	  catch_command_errors (source_script, cmdarg_p.string,
-				!batch_flag);
+	  ret = catch_command_errors (source_script, cmdarg_p.string,
+				      !batch_flag);
 	  break;
 	case CMDARG_COMMAND:
-	  catch_command_errors (execute_command, cmdarg_p.string,
-				!batch_flag);
+	  ret = catch_command_errors (execute_command, cmdarg_p.string,
+				      !batch_flag);
 	  break;
 	}
     }
@@ -1134,8 +1147,11 @@ captured_main_1 (struct captured_main_args *context)
 
   if (batch_flag)
     {
+      int error_status = EXIT_FAILURE;
+      int *exit_arg = ret == 0 ? &error_status : NULL;
+
       /* We have hit the end of the batch file.  */
-      quit_force (NULL, 0);
+      quit_force (exit_arg, 0);
     }
 }
 
diff --git a/gdb/testsuite/gdb.base/batch-exit-status.bad-commands b/gdb/testsuite/gdb.base/batch-exit-status.bad-commands
new file mode 100644
index 0000000..4793acb
--- /dev/null
+++ b/gdb/testsuite/gdb.base/batch-exit-status.bad-commands
@@ -0,0 +1 @@
+bork
diff --git a/gdb/testsuite/gdb.base/batch-exit-status.exp b/gdb/testsuite/gdb.base/batch-exit-status.exp
new file mode 100644
index 0000000..bee4d72
--- /dev/null
+++ b/gdb/testsuite/gdb.base/batch-exit-status.exp
@@ -0,0 +1,63 @@
+# Copyright (C) 2018 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check that "gdb -batch" exits with appropriate status.
+
+standard_testfile
+
+set good_commands "$srcdir/$subdir/batch-exit-status.good-commands"
+set bad_commands "$srcdir/$subdir/batch-exit-status.bad-commands"
+
+proc _test_exit_status {expect_status cmdline_opts} {
+    global gdb_spawn_id
+
+    gdb_exit
+    if {[gdb_spawn_with_cmdline_opts $cmdline_opts] != 0} {
+	fail "spawn"
+	return
+    }
+
+    set result [wait -i $gdb_spawn_id]
+    verbose $result
+    gdb_assert { [lindex $result 2] == 0 }
+    set actual_status [lindex $result 3]
+    gdb_assert { $actual_status == $expect_status }
+}
+
+proc test_exit_status {expect_status cmdline_opts} {
+    with_test_prefix $cmdline_opts {
+	_test_exit_status $expect_status $cmdline_opts
+    }
+}
+
+# gdb -batch with nothing to do should exit 0.
+test_exit_status 0 "-batch"
+
+# Bad command-line options should cause exit 1.
+test_exit_status 1 "-batch -jslkflsdjlkfjlksdjf"
+
+# gdb -batch with good commands should exit 0.
+test_exit_status 0 "-batch -ex \"info source\""
+test_exit_status 0 "-batch -x $good_commands"
+
+# gdb -batch with bad commands should exit 1.
+test_exit_status 1 "-batch -ex \"set not-a-thing 4\""
+test_exit_status 1 "-batch -x $bad_commands"
+
+# Success or failure of the last thing determines the exit code.
+test_exit_status 0 "-batch -ex \"set not-a-thing 4\" -x $good_commands"
+test_exit_status 0 "-batch -x $bad_commands -ex \"info source\""
+test_exit_status 1 "-batch -x $good_commands -x $bad_commands"
+test_exit_status 1 "-batch -x $good_commands -ex \"set not-a-thing 4\""
diff --git a/gdb/testsuite/gdb.base/batch-exit-status.good-commands b/gdb/testsuite/gdb.base/batch-exit-status.good-commands
new file mode 100644
index 0000000..80708a9
--- /dev/null
+++ b/gdb/testsuite/gdb.base/batch-exit-status.good-commands
@@ -0,0 +1 @@
+info mem
-- 
1.8.3.1

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  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
  2 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2018-08-22 14:37 UTC (permalink / raw)
  To: Gary Benson; +Cc: gdb-patches, tom

> From: Gary Benson <gbenson@redhat.com>
> Cc: tom@tromey.com
> Date: Wed, 22 Aug 2018 11:46:53 +0100
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index 16d3d72..6af712a 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -10,6 +10,9 @@
>  * DWARF index cache: GDB can now automatically save indices of DWARF
>    symbols on disk to speed up further loading of the same binaries.
>  
> +* GDB in batch mode now exits with status 1 if the last command to be
> +  executed failed.
> +

This part is OK, thanks.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  2018-08-22 14:37 ` Eli Zaretskii
@ 2018-08-23  8:00   ` Gary Benson
  0 siblings, 0 replies; 12+ messages in thread
From: Gary Benson @ 2018-08-23  8:00 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: gdb-patches

On 22 August 2018 at 15:36, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Gary Benson <gbenson@redhat.com>
> > Cc: tom@tromey.com
> > Date: Wed, 22 Aug 2018 11:46:53 +0100
> >
> > diff --git a/gdb/NEWS b/gdb/NEWS
> > index 16d3d72..6af712a 100644
> > --- a/gdb/NEWS
> > +++ b/gdb/NEWS
> > @@ -10,6 +10,9 @@
> >  * DWARF index cache: GDB can now automatically save indices of DWARF
> >    symbols on disk to speed up further loading of the same binaries.
> >
> > +* GDB in batch mode now exits with status 1 if the last command to be
> > +  executed failed.
> > +
>
> This part is OK, thanks.

Thanks Eli.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  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 16:37 ` Pedro Alves
  2018-08-30 20:26 ` Sergio Durigan Junior
  2 siblings, 0 replies; 12+ messages in thread
From: Pedro Alves @ 2018-08-23 16:37 UTC (permalink / raw)
  To: Gary Benson, gdb-patches; +Cc: tom

On 08/22/2018 11:46 AM, Gary Benson wrote:
> Hi all,
> 
> This patch causes GDB in batch mode to exit with nonzero status
> if the last command to be executed fails.
> 
> Changes since version 1:
>  - I've reworked the patch to not use a global variable.
>  - Behaviour has not changed from version 1.
> 
> Built and regtested on RHEL 7.5 x86_64.
> 
> Ok to commit?
LGTM.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  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 16:37 ` Pedro Alves
@ 2018-08-30 20:26 ` Sergio Durigan Junior
  2018-08-31 13:30   ` Gary Benson
  2 siblings, 1 reply; 12+ messages in thread
From: Sergio Durigan Junior @ 2018-08-30 20:26 UTC (permalink / raw)
  To: Gary Benson; +Cc: gdb-patches, tom

On Wednesday, August 22 2018, Gary Benson wrote:

> Hi all,
>
> This patch causes GDB in batch mode to exit with nonzero status
> if the last command to be executed fails.
>
> Changes since version 1:
>  - I've reworked the patch to not use a global variable.
>  - Behaviour has not changed from version 1.
>
> Built and regtested on RHEL 7.5 x86_64.

Hey, just to make sure this is reported here: I'm seeing failures when
running this test on my Fedora 28 x86_64:

  FAIL: gdb.base/batch-exit-status.exp: -batch -jslkflsdjlkfjlksdjf: $actual_status == $expect_status
  FAIL: gdb.base/batch-exit-status.exp: -batch -ex "set not-a-thing 4": $actual_status == $expect_status
  FAIL: gdb.base/batch-exit-status.exp: -batch -x /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.bad-commands: $actua$
  _status == $expect_status
  FAIL: gdb.base/batch-exit-status.exp: -batch -x /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.good-commands -x /ho$
  e/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.bad-commands: $actual_status == $expect_status
  FAIL: gdb.base/batch-exit-status.exp: -batch -x /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.good-commands -ex "s$
  t not-a-thing 4": $actual_status == $expect_status

This has also been caught by the BuildBot:

  https://sourceware.org/ml/gdb-testers/2018-q3/msg05129.html
  https://sourceware.org/ml/gdb-testers/2018-q3/msg05223.html

Let me know if you need more details.

Thanks,

> Ok to commit?
>
> Thanks,
> Gary
>
> --
> gdb/ChangeLog:
>
> 	PR gdb/13000:
> 	* gdb/main.c (captured_main_1): Exit with nonzero status
> 	in batch mode if the last command to be executed failed.
> 	* NEWS: Mention the above.
>
> gdb/testsuite/ChangeLog:
>
> 	PR gdb/13000:
> 	* gdb.base/batch-exit-status.exp: New file.
> 	* gdb.base/batch-exit-status.good-commands: Likewise.
> 	* gdb.base/batch-exit-status.bad-commands: Likewise.
> ---
>  gdb/ChangeLog                                      |  7 ++
>  gdb/NEWS                                           |  3 +
>  gdb/main.c                                         | 78 +++++++++++++---------
>  gdb/testsuite/ChangeLog                            |  7 ++
>  .../gdb.base/batch-exit-status.bad-commands        |  1 +
>  gdb/testsuite/gdb.base/batch-exit-status.exp       | 63 +++++++++++++++++
>  .../gdb.base/batch-exit-status.good-commands       |  1 +
>  7 files changed, 129 insertions(+), 31 deletions(-)
>  create mode 100644 gdb/testsuite/gdb.base/batch-exit-status.bad-commands
>  create mode 100644 gdb/testsuite/gdb.base/batch-exit-status.exp
>  create mode 100644 gdb/testsuite/gdb.base/batch-exit-status.good-commands
>
> diff --git a/gdb/NEWS b/gdb/NEWS
> index 16d3d72..6af712a 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -10,6 +10,9 @@
>  * DWARF index cache: GDB can now automatically save indices of DWARF
>    symbols on disk to speed up further loading of the same binaries.
>  
> +* GDB in batch mode now exits with status 1 if the last command to be
> +  executed failed.
> +
>  * New commands
>  
>  frame apply [all | COUNT | -COUNT | level LEVEL...] [FLAG]... COMMAND
> diff --git a/gdb/main.c b/gdb/main.c
> index e925128..61644cd 100644
> --- a/gdb/main.c
> +++ b/gdb/main.c
> @@ -486,6 +486,7 @@ captured_main_1 (struct captured_main_args *context)
>    int i;
>    int save_auto_load;
>    struct objfile *objfile;
> +  int ret = 1;
>  
>  #ifdef HAVE_USEFUL_SBRK
>    /* Set this before constructing scoped_command_stats.  */
> @@ -986,7 +987,7 @@ captured_main_1 (struct captured_main_args *context)
>       processed; it sets global parameters, which are independent of
>       what file you are debugging or what directory you are in.  */
>    if (system_gdbinit && !inhibit_gdbinit)
> -    catch_command_errors (source_script, system_gdbinit, 0);
> +    ret = catch_command_errors (source_script, system_gdbinit, 0);
>  
>    /* Read and execute $HOME/.gdbinit file, if it exists.  This is done
>       *before* all the command line arguments are processed; it sets
> @@ -994,7 +995,7 @@ captured_main_1 (struct captured_main_args *context)
>       debugging or what directory you are in.  */
>  
>    if (home_gdbinit && !inhibit_gdbinit && !inhibit_home_gdbinit)
> -    catch_command_errors (source_script, home_gdbinit, 0);
> +    ret = catch_command_errors (source_script, home_gdbinit, 0);
>  
>    /* Process '-ix' and '-iex' options early.  */
>    for (i = 0; i < cmdarg_vec.size (); i++)
> @@ -1004,12 +1005,12 @@ captured_main_1 (struct captured_main_args *context)
>        switch (cmdarg_p.type)
>  	{
>  	case CMDARG_INIT_FILE:
> -	  catch_command_errors (source_script, cmdarg_p.string,
> -				!batch_flag);
> +	  ret = catch_command_errors (source_script, cmdarg_p.string,
> +				      !batch_flag);
>  	  break;
>  	case CMDARG_INIT_COMMAND:
> -	  catch_command_errors (execute_command, cmdarg_p.string,
> -				!batch_flag);
> +	  ret = catch_command_errors (execute_command, cmdarg_p.string,
> +				      !batch_flag);
>  	  break;
>  	}
>      }
> @@ -1017,11 +1018,11 @@ captured_main_1 (struct captured_main_args *context)
>    /* Now perform all the actions indicated by the arguments.  */
>    if (cdarg != NULL)
>      {
> -      catch_command_errors (cd_command, cdarg, 0);
> +      ret = catch_command_errors (cd_command, cdarg, 0);
>      }
>  
>    for (i = 0; i < dirarg.size (); i++)
> -    catch_command_errors (directory_switch, dirarg[i], 0);
> +    ret = catch_command_errors (directory_switch, dirarg[i], 0);
>  
>    /* Skip auto-loading section-specified scripts until we've sourced
>       local_gdbinit (which is often used to augment the source search
> @@ -1036,19 +1037,20 @@ captured_main_1 (struct captured_main_args *context)
>        /* The exec file and the symbol-file are the same.  If we can't
>           open it, better only print one error message.
>           catch_command_errors returns non-zero on success!  */
> -      if (catch_command_errors (exec_file_attach, execarg,
> -				!batch_flag))
> -	catch_command_errors (symbol_file_add_main_adapter, symarg,
> -			      !batch_flag);
> +      ret = catch_command_errors (exec_file_attach, execarg,
> +				  !batch_flag);
> +      if (ret != 0)
> +	ret = catch_command_errors (symbol_file_add_main_adapter,
> +				    symarg, !batch_flag);
>      }
>    else
>      {
>        if (execarg != NULL)
> -	catch_command_errors (exec_file_attach, execarg,
> -			      !batch_flag);
> +	ret = catch_command_errors (exec_file_attach, execarg,
> +				    !batch_flag);
>        if (symarg != NULL)
> -	catch_command_errors (symbol_file_add_main_adapter, symarg,
> -			      !batch_flag);
> +	ret = catch_command_errors (symbol_file_add_main_adapter,
> +				    symarg, !batch_flag);
>      }
>  
>    if (corearg && pidarg)
> @@ -1056,9 +1058,14 @@ captured_main_1 (struct captured_main_args *context)
>  	     "a core file at the same time."));
>  
>    if (corearg != NULL)
> -    catch_command_errors (core_file_command, corearg, !batch_flag);
> +    {
> +      ret = catch_command_errors (core_file_command, corearg,
> +				  !batch_flag);
> +    }
>    else if (pidarg != NULL)
> -    catch_command_errors (attach_command, pidarg, !batch_flag);
> +    {
> +      ret = catch_command_errors (attach_command, pidarg, !batch_flag);
> +    }
>    else if (pid_or_core_arg)
>      {
>        /* The user specified 'gdb program pid' or gdb program core'.
> @@ -1067,14 +1074,20 @@ captured_main_1 (struct captured_main_args *context)
>  
>        if (isdigit (pid_or_core_arg[0]))
>  	{
> -	  if (catch_command_errors (attach_command, pid_or_core_arg,
> -				    !batch_flag) == 0)
> -	    catch_command_errors (core_file_command, pid_or_core_arg,
> -				  !batch_flag);
> +	  ret = catch_command_errors (attach_command, pid_or_core_arg,
> +				      !batch_flag);
> +	  if (ret == 0)
> +	    ret = catch_command_errors (core_file_command,
> +					pid_or_core_arg,
> +					!batch_flag);
> +	}
> +      else
> +	{
> +	  /* Can't be a pid, better be a corefile.  */
> +	  ret = catch_command_errors (core_file_command,
> +				      pid_or_core_arg,
> +				      !batch_flag);
>  	}
> -      else /* Can't be a pid, better be a corefile.  */
> -	catch_command_errors (core_file_command, pid_or_core_arg,
> -			      !batch_flag);
>      }
>  
>    if (ttyarg != NULL)
> @@ -1098,7 +1111,7 @@ captured_main_1 (struct captured_main_args *context)
>  	{
>  	  auto_load_local_gdbinit_loaded = 1;
>  
> -	  catch_command_errors (source_script, local_gdbinit, 0);
> +	  ret = catch_command_errors (source_script, local_gdbinit, 0);
>  	}
>      }
>  
> @@ -1118,12 +1131,12 @@ captured_main_1 (struct captured_main_args *context)
>        switch (cmdarg_p.type)
>  	{
>  	case CMDARG_FILE:
> -	  catch_command_errors (source_script, cmdarg_p.string,
> -				!batch_flag);
> +	  ret = catch_command_errors (source_script, cmdarg_p.string,
> +				      !batch_flag);
>  	  break;
>  	case CMDARG_COMMAND:
> -	  catch_command_errors (execute_command, cmdarg_p.string,
> -				!batch_flag);
> +	  ret = catch_command_errors (execute_command, cmdarg_p.string,
> +				      !batch_flag);
>  	  break;
>  	}
>      }
> @@ -1134,8 +1147,11 @@ captured_main_1 (struct captured_main_args *context)
>  
>    if (batch_flag)
>      {
> +      int error_status = EXIT_FAILURE;
> +      int *exit_arg = ret == 0 ? &error_status : NULL;
> +
>        /* We have hit the end of the batch file.  */
> -      quit_force (NULL, 0);
> +      quit_force (exit_arg, 0);
>      }
>  }
>  
> diff --git a/gdb/testsuite/gdb.base/batch-exit-status.bad-commands b/gdb/testsuite/gdb.base/batch-exit-status.bad-commands
> new file mode 100644
> index 0000000..4793acb
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/batch-exit-status.bad-commands
> @@ -0,0 +1 @@
> +bork
> diff --git a/gdb/testsuite/gdb.base/batch-exit-status.exp b/gdb/testsuite/gdb.base/batch-exit-status.exp
> new file mode 100644
> index 0000000..bee4d72
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/batch-exit-status.exp
> @@ -0,0 +1,63 @@
> +# Copyright (C) 2018 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +# Check that "gdb -batch" exits with appropriate status.
> +
> +standard_testfile
> +
> +set good_commands "$srcdir/$subdir/batch-exit-status.good-commands"
> +set bad_commands "$srcdir/$subdir/batch-exit-status.bad-commands"
> +
> +proc _test_exit_status {expect_status cmdline_opts} {
> +    global gdb_spawn_id
> +
> +    gdb_exit
> +    if {[gdb_spawn_with_cmdline_opts $cmdline_opts] != 0} {
> +	fail "spawn"
> +	return
> +    }
> +
> +    set result [wait -i $gdb_spawn_id]
> +    verbose $result
> +    gdb_assert { [lindex $result 2] == 0 }
> +    set actual_status [lindex $result 3]
> +    gdb_assert { $actual_status == $expect_status }
> +}
> +
> +proc test_exit_status {expect_status cmdline_opts} {
> +    with_test_prefix $cmdline_opts {
> +	_test_exit_status $expect_status $cmdline_opts
> +    }
> +}
> +
> +# gdb -batch with nothing to do should exit 0.
> +test_exit_status 0 "-batch"
> +
> +# Bad command-line options should cause exit 1.
> +test_exit_status 1 "-batch -jslkflsdjlkfjlksdjf"
> +
> +# gdb -batch with good commands should exit 0.
> +test_exit_status 0 "-batch -ex \"info source\""
> +test_exit_status 0 "-batch -x $good_commands"
> +
> +# gdb -batch with bad commands should exit 1.
> +test_exit_status 1 "-batch -ex \"set not-a-thing 4\""
> +test_exit_status 1 "-batch -x $bad_commands"
> +
> +# Success or failure of the last thing determines the exit code.
> +test_exit_status 0 "-batch -ex \"set not-a-thing 4\" -x $good_commands"
> +test_exit_status 0 "-batch -x $bad_commands -ex \"info source\""
> +test_exit_status 1 "-batch -x $good_commands -x $bad_commands"
> +test_exit_status 1 "-batch -x $good_commands -ex \"set not-a-thing 4\""
> diff --git a/gdb/testsuite/gdb.base/batch-exit-status.good-commands b/gdb/testsuite/gdb.base/batch-exit-status.good-commands
> new file mode 100644
> index 0000000..80708a9
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/batch-exit-status.good-commands
> @@ -0,0 +1 @@
> +info mem
> -- 
> 1.8.3.1

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  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 15:38     ` [PATCH v2] Indicate batch mode failures by exiting with nonzero status Sergio Durigan Junior
  0 siblings, 2 replies; 12+ messages in thread
From: Gary Benson @ 2018-08-31 13:30 UTC (permalink / raw)
  To: Sergio Durigan Junior; +Cc: gdb-patches, Tom Tromey

On 30 August 2018 at 21:26, Sergio Durigan Junior <sergiodj@redhat.com> wrote:
> On Wednesday, August 22 2018, Gary Benson wrote:
>> This patch causes GDB in batch mode to exit with nonzero status
>> if the last command to be executed fails.
>>
>> Changes since version 1:
>>  - I've reworked the patch to not use a global variable.
>>  - Behaviour has not changed from version 1.
>>
>> Built and regtested on RHEL 7.5 x86_64.
>
> Hey, just to make sure this is reported here: I'm seeing failures when
> running this test on my Fedora 28 x86_64:
>
>   FAIL: gdb.base/batch-exit-status.exp: -batch -jslkflsdjlkfjlksdjf: $actual_status == $expect_status
>   FAIL: gdb.base/batch-exit-status.exp: -batch -ex "set not-a-thing 4": $actual_status == $expect_status
>   FAIL: gdb.base/batch-exit-status.exp: -batch -x /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.bad-commands: $actua$
>   _status == $expect_status
>   FAIL: gdb.base/batch-exit-status.exp: -batch -x /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.good-commands -x /ho$
>   e/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.bad-commands: $actual_status == $expect_status
>   FAIL: gdb.base/batch-exit-status.exp: -batch -x /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.good-commands -ex "s$
>   t not-a-thing 4": $actual_status == $expect_status
>
> This has also been caught by the BuildBot:
>
>   https://sourceware.org/ml/gdb-testers/2018-q3/msg05129.html
>   https://sourceware.org/ml/gdb-testers/2018-q3/msg05223.html
>
> Let me know if you need more details.

Yes please! Is it failing on *every* platform? I looked in gdb.log.xz
but there's no output from GDB, only the PASS/FAIL lines.  So I don't
really know what to do, I can't reproduce :/

Cheers,
Gary

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  2018-08-31 13:30   ` Gary Benson
@ 2018-08-31 14:33     ` Tom Tromey
  2018-08-31 14:42       ` Pedro Alves
  2018-08-31 15:38     ` [PATCH v2] Indicate batch mode failures by exiting with nonzero status Sergio Durigan Junior
  1 sibling, 1 reply; 12+ messages in thread
From: Tom Tromey @ 2018-08-31 14:33 UTC (permalink / raw)
  To: Gary Benson; +Cc: Sergio Durigan Junior, gdb-patches, Tom Tromey

>>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:

Gary> Yes please! Is it failing on *every* platform? I looked in gdb.log.xz
Gary> but there's no output from GDB, only the PASS/FAIL lines.  So I don't
Gary> really know what to do, I can't reproduce :/

It fails for me too.  I ran with -v and saw this in the .log:

    RESULT = 11271 exp6 0 0
    PASS: gdb.base/batch-exit-status.exp: -batch: [lindex $result 2] == 0
    PASS: gdb.base/batch-exit-status.exp: -batch: $actual_status == $expect_status
    Quitting /home/tromey/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/tromey/gdb/build/gdb/testsuite/../data-directory 
    doing kill, pid is 11271
    Spawning /home/tromey/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/tromey/gdb/build/gdb/testsuite/../data-directory -batch -jslkflsdjlkfjlksdjf
    RESULT = 11271 exp6 0 0
    PASS: gdb.base/batch-exit-status.exp: -batch -jslkflsdjlkfjlksdjf: [lindex $result 2] == 0
    FAIL: gdb.base/batch-exit-status.exp: -batch -jslkflsdjlkfjlksdjf: $actual_status == $expect_status
    Quitting /home/tromey/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/tromey/gdb/build/gdb/testsuite/../data-directory 
    doing kill, pid is 11271


Note how the PID doesn't change.

I suspect that what is happening is that gdb_spawn_id isn't being reset,
and so we're hitting this code in default_gdb_spawn:

    if [info exists gdb_spawn_id] {
	return 0
    }

Something has to unset this after each invocation.
Maybe calling clear_gdb_spawn_id, but I don't know if that's best or if
there should be something else.

Tom

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  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
  0 siblings, 1 reply; 12+ messages in thread
From: Pedro Alves @ 2018-08-31 14:42 UTC (permalink / raw)
  To: Tom Tromey, Gary Benson; +Cc: Sergio Durigan Junior, gdb-patches

On 08/31/2018 03:32 PM, Tom Tromey wrote:

> Maybe calling clear_gdb_spawn_id, but I don't know if that's best or if
> there should be something else.

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?

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH v2] Indicate batch mode failures by exiting with nonzero status
  2018-08-31 13:30   ` Gary Benson
  2018-08-31 14:33     ` Tom Tromey
@ 2018-08-31 15:38     ` Sergio Durigan Junior
  1 sibling, 0 replies; 12+ messages in thread
From: Sergio Durigan Junior @ 2018-08-31 15:38 UTC (permalink / raw)
  To: Gary Benson; +Cc: gdb-patches, Tom Tromey

On Friday, August 31 2018, Gary Benson wrote:

> On 30 August 2018 at 21:26, Sergio Durigan Junior <sergiodj@redhat.com> wrote:
>> On Wednesday, August 22 2018, Gary Benson wrote:
>>> This patch causes GDB in batch mode to exit with nonzero status
>>> if the last command to be executed fails.
>>>
>>> Changes since version 1:
>>>  - I've reworked the patch to not use a global variable.
>>>  - Behaviour has not changed from version 1.
>>>
>>> Built and regtested on RHEL 7.5 x86_64.
>>
>> Hey, just to make sure this is reported here: I'm seeing failures when
>> running this test on my Fedora 28 x86_64:
>>
>>   FAIL: gdb.base/batch-exit-status.exp: -batch -jslkflsdjlkfjlksdjf: $actual_status == $expect_status
>>   FAIL: gdb.base/batch-exit-status.exp: -batch -ex "set not-a-thing 4": $actual_status == $expect_status
>>   FAIL: gdb.base/batch-exit-status.exp: -batch -x
>> /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.bad-commands:
>> $actua$
>>   _status == $expect_status
>>   FAIL: gdb.base/batch-exit-status.exp: -batch -x
>> /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.good-commands
>> -x /ho$
>>   e/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.bad-commands: $actual_status == $expect_status
>>   FAIL: gdb.base/batch-exit-status.exp: -batch -x
>> /home/sergio/work/src/git/binutils-gdb/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/batch-exit-status.good-commands
>> -ex "s$
>>   t not-a-thing 4": $actual_status == $expect_status
>>
>> This has also been caught by the BuildBot:
>>
>>   https://sourceware.org/ml/gdb-testers/2018-q3/msg05129.html
>>   https://sourceware.org/ml/gdb-testers/2018-q3/msg05223.html
>>
>> Let me know if you need more details.
>
> Yes please! Is it failing on *every* platform? I looked in gdb.log.xz
> but there's no output from GDB, only the PASS/FAIL lines.  So I don't
> really know what to do, I can't reproduce :/

Hey Gary,

At least according to the BuildBot, the test is failing on Fedora x86_64
(F-28).  I don't see the failures on s390x, but maybe that's because
they're running old systems...

I guess you might be able to reproduce this if you run the test on a
Fedora 28 machine/VM.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [PATCH] Fix batch exit status test failure on Fedora 28
  2018-08-31 14:42       ` Pedro Alves
@ 2018-09-03 16:12         ` Gary Benson
  2018-09-04 11:39           ` Pedro Alves
  0 siblings, 1 reply; 12+ messages in thread
From: Gary Benson @ 2018-09-03 16:12 UTC (permalink / raw)
  To: gdb-patches; +Cc: Pedro Alves, Sergio Durigan Junior, Tom Tromey

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
the testcase won't hang forever on failure as fixed in
gdb.base/quit.exp by commit 15763a09d4aea85fc3153d6746c040dd48565637.

Is this ok to commit?

Thanks,
Gary

--
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.
---
 gdb/testsuite/ChangeLog                      |  5 +++++
 gdb/testsuite/gdb.base/batch-exit-status.exp | 17 ++++++++++++-----
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.base/batch-exit-status.exp b/gdb/testsuite/gdb.base/batch-exit-status.exp
index bee4d72..3b5de59 100644
--- a/gdb/testsuite/gdb.base/batch-exit-status.exp
+++ b/gdb/testsuite/gdb.base/batch-exit-status.exp
@@ -29,11 +29,18 @@ proc _test_exit_status {expect_status cmdline_opts} {
 	return
     }
 
-    set result [wait -i $gdb_spawn_id]
-    verbose $result
-    gdb_assert { [lindex $result 2] == 0 }
-    set actual_status [lindex $result 3]
-    gdb_assert { $actual_status == $expect_status }
+    gdb_test_multiple "" "run til exit" {
+	eof {
+	    set result [wait -i $gdb_spawn_id]
+	    verbose $result
+
+	    gdb_assert { [lindex $result 2] == 0 }
+	    gdb_assert { [lindex $result 3] == $expect_status }
+
+	    remote_close host
+	    clear_gdb_spawn_id
+	}
+    }
 }
 
 proc test_exit_status {expect_status cmdline_opts} {
-- 
1.8.3.1

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Fix batch exit status test failure on Fedora 28
  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
  0 siblings, 1 reply; 12+ messages in thread
From: Pedro Alves @ 2018-09-04 11:39 UTC (permalink / raw)
  To: Gary Benson, gdb-patches; +Cc: Sergio Durigan Junior, Tom Tromey

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.

> Is this ok to commit?

OK.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] Fix batch exit status test failure on Fedora 28
  2018-09-04 11:39           ` Pedro Alves
@ 2018-09-04 14:37             ` Gary Benson
  0 siblings, 0 replies; 12+ messages in thread
From: Gary Benson @ 2018-09-04 14:37 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb-patches, Sergio Durigan Junior, Tom Tromey

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2018-09-04 14:37 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2018-08-31 15:38     ` [PATCH v2] Indicate batch mode failures by exiting with nonzero status Sergio Durigan Junior

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).