gdb -batch always exits with status 0

gdb -batch always exits with status 0

[Gary Benson]

Hi all,

I've been working on fixing PR gdb/13000, which is that GDB in batch
mode always exits with status 0 despite the manual saying it should
exit with nonzero status on error.  The latter is what I'd intuitively
expect, so I'm looking at fixing GDB to match the docs rather than
fixing the docs to match GDB.

A narrow fix to make GDB match the docs is actually fairly simple,
but I'm bothered that not only does gdb -batch always exit with
status 0, it actually continues over any number of errors before
doing so.  So you can do something like:

  bash$ echo nonsense > cmds
  bash$ echo garbage > .gdbinit
  bash$ gdb -batch -iex invalid-command -ex also-invalid \
          -cd /no/such/directory -p 1 -batch -ix /does/not/exist \
	  -x cmds
  Undefined command: "invalid-command".  Try "help".
  warning: /does/not/exist: No such file or directory
  /no/such/directory: No such file or directory.
  ptrace: Operation not permitted.
  .gdbinit:1: Error in sourced command file:
  Undefined command: "garbage".  Try "help".
  Undefined command: "also-invalid".  Try "help".
  cmds:1: Error in sourced command file:
  Undefined command: "nonsense".  Try "help".
  bash$ echo $?
  0

Would anybody object to my changing GDB's behaviour to terminate
on the first error in batch mode?

(I'd also like to remove the 'Try "help".' suffix when in batch mode,
though I'd likely do that in a separate patch.)

Cheers,
Gary

--
https://gbenson.net/

Re: gdb -batch always exits with status 0

[Ruslan Kabatsayev]

Hi,

On 5 July 2018 at 17:47, Gary Benson <gbenson@redhat.com> wrote:
> Hi all,
>
> I've been working on fixing PR gdb/13000, which is that GDB in batch
> mode always exits with status 0 despite the manual saying it should
> exit with nonzero status on error.  The latter is what I'd intuitively
> expect, so I'm looking at fixing GDB to match the docs rather than
> fixing the docs to match GDB.
>
> A narrow fix to make GDB match the docs is actually fairly simple,
> but I'm bothered that not only does gdb -batch always exit with
> status 0, it actually continues over any number of errors before
> doing so.  So you can do something like:
>
>   bash$ echo nonsense > cmds
>   bash$ echo garbage > .gdbinit
>   bash$ gdb -batch -iex invalid-command -ex also-invalid \
>           -cd /no/such/directory -p 1 -batch -ix /does/not/exist \
>           -x cmds
>   Undefined command: "invalid-command".  Try "help".
>   warning: /does/not/exist: No such file or directory
>   /no/such/directory: No such file or directory.
>   ptrace: Operation not permitted.
>   .gdbinit:1: Error in sourced command file:
>   Undefined command: "garbage".  Try "help".
>   Undefined command: "also-invalid".  Try "help".
>   cmds:1: Error in sourced command file:
>   Undefined command: "nonsense".  Try "help".
>   bash$ echo $?
>   0
>
> Would anybody object to my changing GDB's behaviour to terminate
> on the first error in batch mode?

On the one hand, this totally makes sense. But on the other, can we
prevent exit if we e.g. expect a possible error and do the necessary
steps to fix it? An example use case: before starti command appeared,
it could be simulated by the following:

b *0
r
d 1

The above (unconditional!) sequence of commands would error on `r`,
but the side effect of the whole sequence would be the same as the
modern starti command. Your change would invalidate similar use cases
in batch mode.

>
> (I'd also like to remove the 'Try "help".' suffix when in batch mode,
> though I'd likely do that in a separate patch.)
>
> Cheers,
> Gary
>
> --
> https://gbenson.net/

Re: gdb -batch always exits with status 0

[Paul Smith]

On Thu, 2018-07-05 at 15:47 +0100, Gary Benson wrote:
> Would anybody object to my changing GDB's behaviour to terminate
> on the first error in batch mode?

I would definitely not like this.  Often I write batch files that are
used to collect information about cores (or running processes); if some
aspect of the core is not as I expect, or values are optimized out, or
some operation fails for whatever reason, I definitely do not want my
batch processing to stop.  I want it to continue so I can get as much
information as possible.

If a "stop on error" mode is needed then there should be a separate
option to GDB such as '-batch-fail' or whatever for that, IMO.

Also, it would be nice if there were a way to distinguish between "bad
command line/core file/executable and I couldn't start debugging", and
"I loaded everything but some commands didn't work".  But that may be a
separate operation.

Re: gdb -batch always exits with status 0

[Gary Benson]

Paul Smith wrote:
> On Thu, 2018-07-05 at 15:47 +0100, Gary Benson wrote:
> > Would anybody object to my changing GDB's behaviour to terminate
> > on the first error in batch mode?
> 
> I would definitely not like this.  Often I write batch files that
> are used to collect information about cores (or running processes);
> if some aspect of the core is not as I expect, or values are
> optimized out, or some operation fails for whatever reason, I
> definitely do not want my batch processing to stop.  I want it to
> continue so I can get as much information as possible.
> 
> If a "stop on error" mode is needed then there should be a separate
> option to GDB such as '-batch-fail' or whatever for that, IMO.

Paul, Ruslan, would it be acceptable to you if I:

  1) changed the default behaviour to exit 1 on the first error
  2) added an option (e.g. -ignore-errors) to revert to the current
     behaviour.

Thanks,
Gary

Re: gdb -batch always exits with status 0

[Ruslan Kabatsayev]

On Fri, 17 Aug 2018 at 14:03, Gary Benson <gbenson@redhat.com> wrote:
>
> Paul Smith wrote:
> > On Thu, 2018-07-05 at 15:47 +0100, Gary Benson wrote:
> > > Would anybody object to my changing GDB's behaviour to terminate
> > > on the first error in batch mode?
> >
> > I would definitely not like this.  Often I write batch files that
> > are used to collect information about cores (or running processes);
> > if some aspect of the core is not as I expect, or values are
> > optimized out, or some operation fails for whatever reason, I
> > definitely do not want my batch processing to stop.  I want it to
> > continue so I can get as much information as possible.
> >
> > If a "stop on error" mode is needed then there should be a separate
> > option to GDB such as '-batch-fail' or whatever for that, IMO.
>
> Paul, Ruslan, would it be acceptable to you if I:
>
>   1) changed the default behaviour to exit 1 on the first error
>   2) added an option (e.g. -ignore-errors) to revert to the current
>      behaviour.

Ideally, I'd like to have a more fine-grained way to choose which
commands' errors are to be ignored. But if it's much harder to
implement, the way you suggest is fine with me.

>
> Thanks,
> Gary

Re: gdb -batch always exits with status 0

[Paul Smith]

On Fri, 2018-08-17 at 12:03 +0100, Gary Benson wrote:
> Paul, Ruslan, would it be acceptable to you if I:
> 
>   1) changed the default behaviour to exit 1 on the first error
>   2) added an option (e.g. -ignore-errors) to revert to the current
>      behaviour.

[I'm on vacation until next week so may not be responding immediately]

Well it would not be ideal as I'd need to go through all my scripts
etc. and modify them to add an extra argument.

I guess I'm not really sure why we want to change the default behavior
here.  Do we have people requesting this change?  I haven't seen a
groundswell of people saying they were confused becuase they expected a
different behavior, and the current behavior has good and useful
reasons for existing (i.e., not just an oversight).

Wouldn't the most sensible/least impactful way forward be to leave the
current behavior as-is, and then if people want a different behavior
add a new option they can use to request it?

However, I'm not doing the work so if that's the way GDB devs want to
have it work I will change my usage.

Cheers!

Re: gdb -batch always exits with status 0

[Gary Benson]

Paul Smith wrote:
> On Fri, 2018-08-17 at 12:03 +0100, Gary Benson wrote:
> > Paul, Ruslan, would it be acceptable to you if I:
> > 
> >   1) changed the default behaviour to exit 1 on the first error
> >   2) added an option (e.g. -ignore-errors) to revert to the current
> >      behaviour.
> 
> [I'm on vacation until next week so may not be responding immediately]
> 
> Well it would not be ideal as I'd need to go through all my scripts
> etc. and modify them to add an extra argument.

How much work would this be for you?  Minutes, hours, days, weeks?

> I guess I'm not really sure why we want to change the default
> behavior here.  Do we have people requesting this change?  I haven't
> seen a groundswell of people saying they were confused becuase they
> expected a different behavior, and the current behavior has good and
> useful reasons for existing (i.e., not just an oversight).

There isn't a groundswell of people, no.  I started investigating an
orthoganal issue, that the manual says GDB in batch mode exits with
nonzero status to indicate error, but in reality GDB always exits with
status 0.  It should be a trivial fix, except that the way GDB
continues past errors makes it difficult to implement--exit nonzero
for any error, or the last error, or only some errors... which?
Also, exactly which statements get executed if errors occur isn't
exactly consistent.  And all that disappears when you say, ok, lets
just exit nonzero at the first error, which is what I'd intuitively
expected would happen.

> Wouldn't the most sensible/least impactful way forward be to leave
> the current behavior as-is, and then if people want a different
> behavior add a new option they can use to request it?

It would be the least impactful way, sure, but my point is that GDB
doesn't operate in an intuitive way, and my view is that whatever is
intuitive should be the default.  Having to request it with a special
flag makes GDB harder for new users. 

Cheers,
Gary

Re: gdb -batch always exits with status 0

[Ruslan Kabatsayev]

On Fri, 17 Aug 2018 at 18:23, Gary Benson <gbenson@redhat.com> wrote:
>
> It would be the least impactful way, sure, but my point is that GDB
> doesn't operate in an intuitive way, and my view is that whatever is
> intuitive should be the default.  Having to request it with a special
> flag makes GDB harder for new users.

Not sure about intuitiveness of early exit, but we have an example of
the converse: bash (and other shells). Namely, by default it executes
all the commands, exits with the exit status of the last command
executed. But you can `set -e`, and then first failing command will
stop processing. But then, there do exist means to suppress failure
(e.g. `badCommand && true`), which GDB doesn't seem to have.

Re: gdb -batch always exits with status 0

[Gary Benson]

Ruslan Kabatsayev wrote:
> On Fri, 17 Aug 2018 at 18:23, Gary Benson <gbenson@redhat.com> wrote:
> >
> > It would be the least impactful way, sure, but my point is that
> > GDB doesn't operate in an intuitive way, and my view is that
> > whatever is intuitive should be the default.  Having to request it
> > with a special flag makes GDB harder for new users.
> 
> Not sure about intuitiveness of early exit, but we have an example
> of the converse: bash (and other shells). Namely, by default it
> executes all the commands, exits with the exit status of the last
> command executed. But you can `set -e`, and then first failing
> command will stop processing. But then, there do exist means to
> suppress failure (e.g. `badCommand && true`), which GDB doesn't seem
> to have.

Shells are the only example I could think of.  And I wonder what
proportion of shell scripts start with 'set -e' :)  Having to add
that is the kind of thing I mean about making things harder for
new users.

Cheers,
Gary

Re: gdb -batch always exits with status 0

[Pedro Alves]

On 08/17/2018 05:03 PM, Gary Benson wrote:
> Ruslan Kabatsayev wrote:
>> On Fri, 17 Aug 2018 at 18:23, Gary Benson <gbenson@redhat.com> wrote:
>>>
>>> It would be the least impactful way, sure, but my point is that
>>> GDB doesn't operate in an intuitive way, and my view is that
>>> whatever is intuitive should be the default.  Having to request it
>>> with a special flag makes GDB harder for new users.
>>
>> Not sure about intuitiveness of early exit, but we have an example
>> of the converse: bash (and other shells). Namely, by default it
>> executes all the commands, exits with the exit status of the last
>> command executed. But you can `set -e`, and then first failing
>> command will stop processing. But then, there do exist means to
>> suppress failure (e.g. `badCommand && true`), which GDB doesn't seem
>> to have.
> 
> Shells are the only example I could think of.  And I wonder what
> proportion of shell scripts start with 'set -e' :)  Having to add
> that is the kind of thing I mean about making things harder for
> new users.

To me, it feels like you're not discussing the real issue.

GDB _does_ stop processing scripts on first error.

 $ cat file1 
 fail1
 fail2
 fail3
 $ cat file2 
 fail4
 fail5
 fail6
 $ gdb -q -x file1 -x file2
 file1:1: Error in sourced command file:
 Undefined command: "fail1".  Try "help".
 file2:1: Error in sourced command file:
 Undefined command: "fail4".  Try "help".                                                                                                                                    
 (gdb)   

Note, fail2, fail3, fail5 and fail6 were not run.

What GDB does not do is consider an error from inside a script
sourced from the shell command line as reason to fail out.  So for
example above, I think Gary is arguing that GDB should have behaved
like this:

 $ gdb -q -x file1 -x file2
 file1:1: Error in sourced command file:
 Undefined command: "fail1".  Try "help".
 (gdb)   

I.e., "file2" was not sourced.

In this aspect, "-ex" behaves exactly like "-x" -- you can think
of -ex as gdb internally pasting the -ex command in a script
and then sourcing it with -x.

Thanks,
Pedro Alves

Re: gdb -batch always exits with status 0

[Gary Benson]

On 17 August 2018 at 19:29, Pedro Alves <palves@redhat.com> wrote:
> To me, it feels like you're not discussing the real issue.
>
> GDB _does_ stop processing scripts on first error.
>
>  $ cat file1
>  fail1
>  fail2
>  fail3
>  $ cat file2
>  fail4
>  fail5
>  fail6
>  $ gdb -q -x file1 -x file2
>  file1:1: Error in sourced command file:
>  Undefined command: "fail1".  Try "help".
>  file2:1: Error in sourced command file:
>  Undefined command: "fail4".  Try "help".
>  (gdb)
>
> Note, fail2, fail3, fail5 and fail6 were not run.
>
> What GDB does not do is consider an error from inside a script
> sourced from the shell command line as reason to fail out.  So for
> example above, I think Gary is arguing that GDB should have behaved
> like this:
>
>  $ gdb -q -x file1 -x file2
>  file1:1: Error in sourced command file:
>  Undefined command: "fail1".  Try "help".
>  (gdb)
>
> I.e., "file2" was not sourced.
>
> In this aspect, "-ex" behaves exactly like "-x" -- you can think
> of -ex as gdb internally pasting the -ex command in a script
> and then sourcing it with -x.

I don't know if I'm overthinking things, but basically I looked at
the different places a command error can occur:

  /etc/gdbinit
  ~/.gdbinit
  -ix
  -iex
  -cd
  -d
  PROG
  -p
  CORE
  .gdbinit in cwd
  -x
  -ex

For some of these it does seem to make sense to exit, e.g. if
processing "-p PID" fails to end up attached to a process.
But nobody is asking for change, nobody's having a problem
with this, so I'm going to leave this here.

Cheers,
Gary