[Bug cli/27125] New: unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[Bug cli/27125] New: unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[kelly at 219design dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

            Bug ID: 27125
           Summary: unwanted interaction of [-ex "bt"] with [-batch
                    -return-child-result]. used to work in gdb 8.1
           Product: gdb
           Version: 9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: cli
          Assignee: unassigned at sourceware dot org
          Reporter: kelly at 219design dot com
  Target Milestone: ---

Steps to reproduce.

Use gdb 9.2

Mine:
    gdb --version
    GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2

Try both the following at the command line:

gdb -n -batch -return-child-result -ex "set args /tmp/hork" -ex "run" -ex "bt"
/bin/touch

    [Inferior 1 (process 2728) exited normally]
    No stack.


gdb -n -batch -return-child-result -ex "set args /hork_root" -ex "run" -ex "bt"
/bin/touch

    /bin/touch: cannot touch '/hork_root': Permission denied
    [Inferior 1 (process 2764) exited with code 01]
    No stack.

Note that in the second invocation, gdb prints "inferior... exited with code
01".  That is accurate.  In the first invocation, the inferior exit code is
zero (as expected), and in the second invocation, the inferior exit code is
non-zero (as expected).

What's wrong?

In both invocations, the exit code of the gdb process itself is 1. This is
surprising and unwanted, since I am invoking gdb with the
"-return-child-result" option.

What do I expect?

When using "-return-child-result", I expect the gdb process to exit 1
if-and-only-if the inferior exits with 1, and I expect the gdb process to exit
0 if-and-only-if the inferior exits with 0.

What I just described as expected behavior is also the actual observed behavior
when using gdb 8.1.

The problem can be (in part) alleviated by removing [-ex "bt"]

These return 0 and 1, respectively:

gdb -n -batch -return-child-result -ex "set args /tmp/hork" -ex "run" 
/bin/touch

gdb -n -batch -return-child-result -ex "set args /hork_root" -ex "run" 
/bin/touch


I have been using batch gdb in the manner described above as part of various
continuous integration jobs.

The benefit of using -return-child-result is so that I can use "bash -e" in the
continuous integration wrapper, and the job will fail fast if the process
launched under gdb does not exit successfully. The benefit of using [-ex "bt"]
is so that if the process under gdb crashes, then the continuous integration
log will contain a stack trace of the crash. This has been useful in capturing
stack traces of crashes that happen only rarely.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/27125] unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[kelly at 219design dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

--- Comment #1 from kelly at 219design dot com ---
I have located the commit that introduced the behavior change. I can clearly
see that the change was intentional, and yet I would still like to question
whether "-return-child-result" should be given special consideration.

Commit that introduced the unexpected "-return-child-result" outcome:

commit b0f492b90f3d13da8ac80437e6ecb9a87db4a75b (refs/bisect/bad)
Author: Gary Benson <gbenson@redhat.com>
Date:   Wed Aug 29 16:11:50 2018 +0100

    Indicate batch mode failures by exiting with nonzero status

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

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/27125] unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[kelly at 219design dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

kelly at 219design dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kelly at 219design dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/27125] unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[kelly at 219design dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

--- Comment #2 from kelly at 219design dot com ---
prior to commit b0f492b90f3d13da8a, we had:


  if (batch_flag)
    {
      /* We have hit the end of the batch file.  */
      quit_force (NULL, 0);
    }


after that commit, we have (and currently still have):

  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 (exit_arg, 0);
    }

In the absence of "-return-child-result", I wholeheartedly agree with the
outcome of commit b0f492b90f3d13da8a.

When using "-return-child-result", however, it isn't obvious to me whether the
new behavior is best.

I would pose the question to users of "-return-child-result":

When "-return-child-result" is active, should that result in executing the old
(pre-b0f492b90f3d13da8a) behavior of quit_force? The first variation shown
above?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/27125] unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[kelly at 219design dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

--- Comment #3 from kelly at 219design dot com ---
My own limited use case is still adequately described using:

    gdb -n -batch -return-child-result -ex "set args /tmp/hork" -ex "run" -ex
"bt" /bin/touch

I wish for gdb to exit 0 in this case.

If my bug report is deemed invalid/not-a-bug, then my own use case could also
be solved if there is a way for me to replace just this part of my invocation:

    -ex "bt"

... with some replacement that will produce a backtrace if the program is in an
error state, and that will silently and error-less-ly skip trying to print a
backtrace if the inferior has exited cleanly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/27125] unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[kelly at 219design dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

--- Comment #4 from kelly at 219design dot com ---
I have found a workaround. If I add a second copy of [-ex "run"] then I can
achieve essentially the results that I enjoyed previously.

So with:

gdb -n -batch -return-child-result -ex "set args /tmp/hork" -ex "run" -ex "bt"
-ex "run" /bin/touch

    [Inferior 1 (process 19143) exited normally]
    No stack.
    [Inferior 1 (process 19147) exited normally]

Note the repetition:

   ex "run" -ex "bt" -ex "run"

Then I can enjoy my prior continuous integration benefits:

Benefit 1: If the inferior crashes, then my outer bash script (using bash -e)
terminates, but I also will see the backtrace printed by gdb.

Benefit 2: If the inferior does not crash, then the gdb instance exits 0 and my
continuous integration bash script (using bash -e) can continue onward.

The downsides (which I consider minimal) are:

- extra time spent in CI to run my target (the inferior) twice, and
- the possibility that if an intermittent crash happens on the SECOND run
inside gdb, then I will not be able to capture that backtrace

Now my fear is that upon seeing:

   ex "run" -ex "bt" -ex "run"

Someone will decide that gdb should exit 1 immediately upon hitting that [-ex
"bt"], which will deprive me of my new-found workaround. 

So again I will return to the following idea:

   "-return-child-result" should probably override the batch-failure behavior
introduced in commit b0f492b90f3d13d

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug cli/27125] unwanted interaction of [-ex "bt"] with [-batch -return-child-result]. used to work in gdb 8.1

[cbiesinger at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27125

Christian Biesinger <cbiesinger at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.