Re: GDB 8.2.90 available for testing

[Pedro Franco de Carvalho <pedromfc at linux dot ibm dot com>]

Joel Brobecker <brobecker@adacore.com> writes:

Hello,

There is a regression in the testsuite itself, triggered by errors being
raised from within gdb_test_multiple.  This looks like a dejagnu issue,
but it started happening due to a commit that was introduced for this
version, and it can cause the testsuite to hang.

The commit that triggers this is:

fe1a5cad302b5535030cdf62895e79512713d738
[gdb/testsuite] Log wait status on process no longer exists error

The issue is that this commit introduces a new "eof" block in
gdb_test_multiple.  It doesn't look incorrect to me, but dejagnu uses
this block as a "default" action when an error is raised from within the
commands inside a call to gdb_test_multiple, which means that it can be
executed even when there was no actual eof and the GDB process is still
running, so the wait introduced in the commit that tries to get the exit
status of GDB hangs forever, while GDB itself waits for input.

This only happens when there are internal testsuite errors (not testcase
failures).  I had noticed it before but the issue that caused the error
and triggered this problem was resolved.  I saw it again now when I ran
the testsuite on a system that restricts ptrace attach operations, which
causes an error in "gdb.multi/multi-term-settings.exp", which then hangs
the testsuite.

This can be reproduced more easily with a testcase such as:

gdb_start

gdb_test_multiple "show version" "show version" {
	    -re ".*" {
		error "forced error"
	    }
}

I'm not sure if there is a proper way to work around this in GDB, but it
would be useful so that the testsuite doesn't hang in these cases.

Adding an empty "default" block at the end of the expect body in
gdb_test_multiple doesn't work, because the dejagnu routine that parses
this body and selects the default block to execute after an error is
affected by the comments in the body (since they are also parsed).  This
is proc remote_expect (in dejagnu/lib/remote.exp).  In fact, there is
already a second eof block that isn't used due to this issue.

If this comment in gdb_test_multiple

# patterns below apply to any spawn id specified.

Is changed to

# The patterns below apply to any spawn id specified.

Then the second eof block is selected and there is no hang-up.

Any comment at that same place with an even-numbered of tokens also
works.  Of course, this is an ugly solution, and there could be other
weird side-effects.

Alternatively, the GDB commit that introduced this new eof block could
be reverted.  This would be unfortunate since it seems useful, but the
comment for proc remote_expect does specify that the eof/default/timeout
block is used as an error handler, just not which one.

Thanks!

--
Pedro Franco de Carvalho