[4/6] testsuite: Don't use expect_background to reap gdbserver

  Pedro Alves <palves@redhat.com> writes:

> +proc gdb_exit {} {
> +    global gdb_spawn_id server_spawn_id
> +    global gdb_prompt
> +
> +    if {[info exists gdb_spawn_id] && [info exists server_spawn_id]} {
> +	send_gdb "monitor exit\n";
> +	gdb_expect {
> +	    -re "$gdb_prompt $" {
> +		exp_continue
> +	    }
> +	    -i "$server_spawn_id" eof {
> +		wait -i $expect_out(spawn_id)
> +		unset server_spawn_id
> +	    }
> +	}
> +    }

Do we need to catch exception here?

I see the error when I run gdb-sigterm.exp with native-gdbserver
on x86_64-linux.

infrun: prepare_to_wait^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
gdb.base/gdb-sigterm.exp: expect eof #0: got eof
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 12 times
ERROR OCCURED: : spawn id exp8 not open
    while executing
"expect {
-i exp8 -timeout 10
            -re "$gdb_prompt $" {
                exp_continue
            }
            -i "$server_spawn_id" eof {
                wait -i $expect_out(spawn_id)
                unse..."
    ("uplevel" body line 1)
    invoked from within

In gdb-sigterm.exp, SIGTERM is sent to GDB and it exits.  However,
Dejagnu or tcl doesn't know this.


> +    close_gdbserver
> +
> +    gdbserver_orig_gdb_exit
> +}

This error terminates the whole testing, so the following tests are
not run.

I wrap the send_gdb and gdb_expect statement above by "catch",
testing looks fine, although error messages are still shown in the
console and gdb.log.
  

On 04/13/2015 12:42 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> +proc gdb_exit {} {
>> +    global gdb_spawn_id server_spawn_id
>> +    global gdb_prompt
>> +
>> +    if {[info exists gdb_spawn_id] && [info exists server_spawn_id]} {
>> +	send_gdb "monitor exit\n";
>> +	gdb_expect {
>> +	    -re "$gdb_prompt $" {
>> +		exp_continue
>> +	    }
>> +	    -i "$server_spawn_id" eof {
>> +		wait -i $expect_out(spawn_id)
>> +		unset server_spawn_id
>> +	    }
>> +	}
>> +    }
> 
> Do we need to catch exception here?

Whoops, yes, looks like it.

> I wrap the send_gdb and gdb_expect statement above by "catch",
> testing looks fine, although error messages are still shown in the
> console and gdb.log.

Why not suppress the error message?  I think you just need to pass
a var name as second parameter to "catch".

Thanks,
Pedro Alves
  

On 13/04/15 13:09, Pedro Alves wrote:
>> I wrap the send_gdb and gdb_expect statement above by "catch",
>> >testing looks fine, although error messages are still shown in the
>> >console and gdb.log.
> Why not suppress the error message?  I think you just need to pass
> a var name as second parameter to "catch".

I did that, but it is useless.  These messages prefixed with
"ERROR OCCURED:" are printed by DejaGNU, lib/remote.exp:remote_expect,

     if {$code == 1} {
         if {[info exists string]} {send_user "ERROR OCCURED: $errorInfo 
$errorCode $string"}

looks we can't prevent DejaGNU invoking send_user.  If this error is
annoying, we can unset gdb_spawn_id at the end of proc do_test in
gdb-sigterm.exp.
  

On 04/13/2015 02:25 PM, Yao Qi wrote:
> On 13/04/15 13:09, Pedro Alves wrote:
>>> I wrap the send_gdb and gdb_expect statement above by "catch",
>>>> testing looks fine, although error messages are still shown in the
>>>> console and gdb.log.
>> Why not suppress the error message?  I think you just need to pass
>> a var name as second parameter to "catch".
> 
> I did that, but it is useless.  These messages prefixed with
> "ERROR OCCURED:" are printed by DejaGNU, lib/remote.exp:remote_expect,
> 
>      if {$code == 1} {
>          if {[info exists string]} {send_user "ERROR OCCURED: $errorInfo 
> $errorCode $string"}
> 
> looks we can't prevent DejaGNU invoking send_user.

I think we should just call raw "expect" instead then.

> If this error is
> annoying, we can unset gdb_spawn_id at the end of proc do_test in
> gdb-sigterm.exp.

I think also need to call wait too?  There are other eof calls in other
tests too and also under lib/  We'd need to do the same to all of those,
and then, at least, we'd need to make default_gdb_exit not skip the
inotify_log_file code too.  I'm not sure I like that direction.

(BTW, that remote host code in default_gdb_exit looks like should be
given the same treatment.)

Thanks,
Pedro Alves