diff mbox

gdb: Unset PROMPT_COMMAND before testing

Message ID 20170616231210.14867-1-andrew.burgess@embecosm.com
State New, archived
Headers

Commit Message

Andrew Burgess June 16, 2017, 11:12 p.m. UTC 
  One of the GDB tests starts up a sub-shell and runs a few commands in
it.  In some cases, a users PROMPT_COMMAND might not work in the
sub-shell GDB starts, which could cause the shell to emit unexpected
warnings or errors, this in turn could cause tests to fail.

The current example is gdb.base/batch-preserve-term-settings.exp, but
there could be others in the future.

I don't see any regressions with this patch, but I do now see 5
additional passes on gdb.base/batch-preserve-term-settings.exp.

OK to apply?

Thanks,
Andrew

---

gdb/testsuite/ChangeLog:

	* lib/gdb.exp (gdb_init): Unset PROMPT_COMMAND.
---
 gdb/testsuite/ChangeLog   | 4 ++++
 gdb/testsuite/lib/gdb.exp | 5 +++++
 2 files changed, 9 insertions(+)

Comments

Yao Qi June 22, 2017, 10:12 a.m. UTC | #1 
Andrew Burgess <andrew.burgess@embecosm.com> writes:

> One of the GDB tests starts up a sub-shell and runs a few commands in
> it.  In some cases, a users PROMPT_COMMAND might not work in the
> sub-shell GDB starts, which could cause the shell to emit unexpected
> warnings or errors, this in turn could cause tests to fail.

What is the concrete output in your case?

>
> The current example is gdb.base/batch-preserve-term-settings.exp, but
> there could be others in the future.
>
> I don't see any regressions with this patch, but I do now see 5
> additional passes on gdb.base/batch-preserve-term-settings.exp.

This patch sets the env for build rather than host, so it doesn't help
in remote host.  Note that I don't think DejaGNU can set env in remote.
Andrew Burgess June 22, 2017, 7:14 p.m. UTC | #2 
* Yao Qi <qiyaoltc@gmail.com> [2017-06-22 11:12:02 +0100]:

> Andrew Burgess <andrew.burgess@embecosm.com> writes:
> 
> > One of the GDB tests starts up a sub-shell and runs a few commands in
> > it.  In some cases, a users PROMPT_COMMAND might not work in the
> > sub-shell GDB starts, which could cause the shell to emit unexpected
> > warnings or errors, this in turn could cause tests to fail.
> 
> What is the concrete output in your case?
> 
> >
> > The current example is gdb.base/batch-preserve-term-settings.exp, but
> > there could be others in the future.
> >
> > I don't see any regressions with this patch, but I do now see 5
> > additional passes on gdb.base/batch-preserve-term-settings.exp.
> 
> This patch sets the env for build rather than host, so it doesn't help
> in remote host.  Note that I don't think DejaGNU can set env in remote.

Thank you for taking the time to look at this patch, but after reading
your feedback and further consideration I now realise that this issue
should really be fixed at my end.

Apologies for wasting your time, and the mailing list noise.

Thanks,
Andrew
diff mbox

Patch

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index a74f97465e..053bc65e09 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -4626,6 +4626,11 @@  proc gdb_init { test_file_name } {
     # especially having color output turned on can cause tests to fail.
     setenv GREP_OPTIONS ""
 
+    # Some tests run a shell.  If a user has PROMPT_COMMAND set then
+    # there's no guarantee that what it's set to will work correctly
+    # within the sub-shells we run.  For safety clear it.
+    setenv PROMPT_COMMAND ""
+
     # Clear $gdbserver_reconnect_p.
     global gdbserver_reconnect_p
     set gdbserver_reconnect_p 1