[Bug gdb/29833] New: [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[Bug gdb/29833] New: [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

            Bug ID: 29833
           Summary: [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor
                    exit
           Product: gdb
           Version: 12.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I ran into:
...
(gdb) monitor exit^M
(gdb) Remote connection closed^M
(gdb) FAIL: gdb.server/monitor-exit-quit.exp: monitor exit
...

First attempt at reproducing didn't work, and got me instead:
...
(gdb) monitor exit^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: monitor exit
...

Build from commit d4c4542312c ("gdb/testsuite: remove use of then keyword from
library files").

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|12.1                        |HEAD

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
I see this now more often, when I run the entire testsuite, but still don't
manage to reproduce it when running the test-case by itself.  Also spotted on
aarch64-linux.

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> I ran into:
> ...
> (gdb) monitor exit^M
> (gdb) Remote connection closed^M
> (gdb) FAIL: gdb.server/monitor-exit-quit.exp: monitor exit
> ...

It's interesting though, we have:
...
gdb_test_no_output "monitor exit"
...
so given the point where the FAIL is produced, the gdb_test_no_output consumes
two prompts.

So maybe this should be
...
gdb_test_no_output -no-prompt-anchor "monitor exit"
...

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
I saw it too on my CI.

In the normal case, the monitor exit command does not cause GDB to realize the
remote connection has closed.  It reads the RSP response ("OK") and that's it. 
I think it does not realize the connection has closed because the remote
connection fd is not in the event loop, and it does not try to read past that
"OK" response.

So, the question is, what happens differently in the failing case for GDB to
realize immediately the connection has closed?

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Sofar, I was not able to reproduce this other than by running the entire
testsuite, which is a bit unpractical.

I've tried the approach of adding debug logging, like so:
...
@@ -51,7 +51,18 @@ set gdbserver_protocol [lindex $res 0]
 set gdbserver_gdbport [lindex $res 1]
 gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport

-gdb_test_no_output "monitor exit"
+gdb_test_no_output "set debug remote 1"
+gdb_test_no_output "set debug event-loop all"
+gdb_test_multiple "monitor exit" "" {
+    -re -wrap "Remote connection closed.*" {
+       fail $gdb_test_name
+    }
+    -re -wrap "" {
+       pass $gdb_test_name
+    }
+}
+gdb_test "set debug event-loop off"
+gdb_test "set debug remote 0"
 gdb_test_no_output "set confirm off"

 set do_cleanup 1
...

And after a entire testsuite run, I have:
...
(gdb) set debug remote 1^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug remote 1
set debug event-loop all^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug event-loop all
[event-loop] handle_file_event: invoking fd file handler `ui-1`^M
monitor exit^M
[remote] Sending packet: $qRcmd,65786974#d7^M
[remote] Packet received: OK^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: monitor exit
[event-loop] handle_file_event: invoking fd file handler `serial`^M
[remote] wait: enter^M
  [event-loop] clear_async_event_handler: clearing async event handler
`remote`^M
[remote] wait: exit^M
Remote connection closed^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug event-loop off
[event-loop] handle_file_event: invoking fd file handler `ui-1`^M
set debug event-loop off^M
(gdb) set debug remote 0^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug remote 0
...

AFAICT, the same behaviour reproduces, it just doesn't cause a fail, either
because of timing or because of less strict matching.

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
And for contrast, when I run the test-case by itself, and disable the restore
of set debug event-loop to trace those to the end, I get:
...
(gdb) set debug remote 1^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug remote 1
set debug event-loop all^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug event-loop all
[event-loop] handle_file_event: invoking fd file handler `ui-1`^M
monitor exit^M
[remote] Sending packet: $qRcmd,65786974#d7^M
[remote] Packet received: OK^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: monitor exit
[event-loop] handle_file_event: invoking fd file handler `ui-1`^M
set debug remote 0^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug remote 0
[event-loop] handle_file_event: invoking fd file handler `ui-1`^M
set confirm off^M
(gdb) FAIL: gdb.server/monitor-exit-quit.exp: set confirm off
[event-loop] handle_file_event: invoking fd file handler `ui-1`^M
quit^M
Remote connection closed^M
PASS: gdb.server/monitor-exit-quit.exp: quit
...

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Simon Marchi from comment #3)
> I saw it too on my CI.
> 
> In the normal case, the monitor exit command does not cause GDB to realize
> the remote connection has closed.  It reads the RSP response ("OK") and
> that's it.  I think it does not realize the connection has closed because
> the remote connection fd is not in the event loop, and it does not try to
> read past that "OK" response.
> 
> So, the question is, what happens differently in the failing case for GDB to
> realize immediately the connection has closed?

So, the first observed difference is:
...
[event-loop] handle_file_event: invoking fd file handler `serial`^M
...
and AFAIU this is a sign that the remote connection fd is in the event loop.

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Using this patch:
...
diff --git a/gdb/remote.c b/gdb/remote.c
index 218bca30d04..1ef9315f2de 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -9471,6 +9471,9 @@ remote_target::readchar (int timeout)
     {
     case SERIAL_EOF:
       remote_unpush_target (this);
+      fprintf (stderr, "Throwing Remote connection closed\n");
+      fflush (stderr);
+      gdb_assert (false);
       throw_error (TARGET_CLOSE_ERROR, _("Remote connection closed"));
       /* no return */
     case SERIAL_ERROR:
...
I generated a backtrace in gdb.log:
...
$ cat gdb.bt  | c++filt 
0x593e04 gdb_internal_backtrace_1
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122
0x593ea7 gdb_internal_backtrace()
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168
0xcd877a internal_vproblem
        /home/vries/gdb_versions/devel/src/gdb/utils.c:401
0xcd8b49 internal_verror(char const*, int, char const*, __va_list_tag*)
        /home/vries/gdb_versions/devel/src/gdb/utils.c:481
0x14345e6 internal_error_loc(char const*, int, char const*, ...)
        /home/vries/gdb_versions/devel/src/gdbsupport/errors.cc:58
0xaa94a8 remote_target::readchar(int)
        /home/vries/gdb_versions/devel/src/gdb/remote.c:9476
0xaaa25b remote_target::getpkt_or_notif_sane_1(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int, int, int*)
        /home/vries/gdb_versions/devel/src/gdb/remote.c:9946
0xaaa649 remote_target::getpkt_or_notif_sane(std::vector<char,
gdb::default_init_allocator<char, std::allocator<char> > >*, int, int*)
        /home/vries/gdb_versions/devel/src/gdb/remote.c:10055
0xaa62b4 remote_target::wait_ns(ptid_t, target_waitstatus*,
enum_flags<target_wait_flag>)
        /home/vries/gdb_versions/devel/src/gdb/remote.c:8128
0xaa6ca2 remote_target::wait(ptid_t, target_waitstatus*,
enum_flags<target_wait_flag>)
        /home/vries/gdb_versions/devel/src/gdb/remote.c:8357
0xc12f46 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
        /home/vries/gdb_versions/devel/src/gdb/target.c:2579
0x86adf9 do_target_wait_1
        /home/vries/gdb_versions/devel/src/gdb/infrun.c:3736
0x86af51 operator()
        /home/vries/gdb_versions/devel/src/gdb/infrun.c:3795
0x86b27f do_target_wait
        /home/vries/gdb_versions/devel/src/gdb/infrun.c:3814
0x86c04c fetch_inferior_event()
        /home/vries/gdb_versions/devel/src/gdb/infrun.c:4172
0x84b13b inferior_event_handler(inferior_event_type)
        /home/vries/gdb_versions/devel/src/gdb/inf-loop.c:41
0xab52c6 remote_async_serial_handler
        /home/vries/gdb_versions/devel/src/gdb/remote.c:14424
0xb5bfef run_async_handler_and_reschedule
        /home/vries/gdb_versions/devel/src/gdb/ser-base.c:138
0xb5c0d4 fd_event
        /home/vries/gdb_versions/devel/src/gdb/ser-base.c:189
0x143544d handle_file_event
        /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:573
0x14359d5 gdb_wait_for_event
        /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:694
0x14348a9 gdb_do_one_event(int)
        /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:264
0x8ffdba start_event_loop
        /home/vries/gdb_versions/devel/src/gdb/main.c:411
0x8ffee0 captured_command_loop
        /home/vries/gdb_versions/devel/src/gdb/main.c:471
0x901666 captured_main
        /home/vries/gdb_versions/devel/src/gdb/main.c:1310
0x9016cc gdb_main(captured_main_args*)
        /home/vries/gdb_versions/devel/src/gdb/main.c:1325
0x41a26d main
        /home/vries/gdb_versions/devel/src/gdb/gdb.c:32
...

I updated the core pattern to:
...
$ cat /proc/sys/kernel/core_pattern
core.%e.%p.%h.%t
...
but that doesn't uniquely identify the core file that's matching this
particular test-case, because in gdb.log we're not posting the pid's of gdb
when spawned.  I'll try again with -v, maybe that will improve things.

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
OK, so with the assert from the previous comment, and this in the test-case:
...
+gdb_test_no_output "maint set internal-error quit yes"
+gdb_test_no_output "maint set internal-error corefile yes"
 gdb_test_no_output "monitor exit"
...
and:
...
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index af538e5c8fb..f82756acbe8 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -2236,6 +2236,8 @@ proc default_gdb_spawn { } {
        return 1
     }

+    verbose -log "spawned GDB PID: [exp_pid -i $res]"
+    
     set gdb_spawn_id $res
     set ::gdb_tty_name $::last_spawn_tty_name
     return 0
...
I managed to generate a core and find it.

Backtrace:
...
(gdb) bt
#0  0x00007f7b0f156cbb in raise () from /lib64/libc.so.6
#1  0x00007f7b0f158355 in abort () from /lib64/libc.so.6
#2  0x0000000000cd8439 in dump_core () at
/home/vries/gdb_versions/devel/src/gdb/utils.c:203
#3  0x0000000000cd8a74 in internal_vproblem(internal_problem *, const char *,
int, const char *, typedef __va_list_tag __va_list_tag *) (problem=0x25f95e0
<internal_error_problem>, 
    file=0x15c9b30 "/home/vries/gdb_versions/devel/src/gdb/remote.c",
line=9476, 
    fmt=0x15c9729 "%s: Assertion `%s' failed.", ap=0x7ffc77c68628)
    at /home/vries/gdb_versions/devel/src/gdb/utils.c:455
#4  0x0000000000cd8b4a in internal_verror (
    file=0x15c9b30 "/home/vries/gdb_versions/devel/src/gdb/remote.c",
line=9476, 
    fmt=0x15c9729 "%s: Assertion `%s' failed.", ap=0x7ffc77c68628)
    at /home/vries/gdb_versions/devel/src/gdb/utils.c:481
#5  0x00000000014345e7 in internal_error_loc (
    file=0x15c9b30 "/home/vries/gdb_versions/devel/src/gdb/remote.c",
line=9476, 
    fmt=0x15c9729 "%s: Assertion `%s' failed.")
    at /home/vries/gdb_versions/devel/src/gdbsupport/errors.cc:58
#6  0x0000000000aa94a9 in remote_target::readchar (this=0x323b4b0, timeout=0)
    at /home/vries/gdb_versions/devel/src/gdb/remote.c:9476
#7  0x0000000000aaa25c in remote_target::getpkt_or_notif_sane_1
(this=0x323b4b0, 
    buf=0x323b4d8, forever=0, expecting_notif=1, is_notif=0x7ffc77c68870)
--Type <RET> for more, q to quit, c to continue without paging--
    at /home/vries/gdb_versions/devel/src/gdb/remote.c:9946
#8  0x0000000000aaa64a in remote_target::getpkt_or_notif_sane (this=0x323b4b0, 
    buf=0x323b4d8, forever=0, is_notif=0x7ffc77c68870)
    at /home/vries/gdb_versions/devel/src/gdb/remote.c:10055
#9  0x0000000000aa62b5 in remote_target::wait_ns (this=0x323b4b0, ptid=..., 
    status=0x7ffc77c68ed8, options=...)
    at /home/vries/gdb_versions/devel/src/gdb/remote.c:8128
#10 0x0000000000aa6ca3 in remote_target::wait (this=0x323b4b0, ptid=..., 
    status=0x7ffc77c68ed8, options=...)
    at /home/vries/gdb_versions/devel/src/gdb/remote.c:8357
#11 0x0000000000c12f47 in target_wait (ptid=..., status=0x7ffc77c68ed8,
options=...)
    at /home/vries/gdb_versions/devel/src/gdb/target.c:2579
#12 0x000000000086adfa in do_target_wait_1 (inf=0x3066e00, ptid=...,
status=0x7ffc77c68ed8, 
    options=...) at /home/vries/gdb_versions/devel/src/gdb/infrun.c:3736
#13 0x000000000086af52 in <lambda(inferior*)>::operator()(inferior *) const (
    __closure=0x7ffc77c68d10, inf=0x3066e00)
    at /home/vries/gdb_versions/devel/src/gdb/infrun.c:3795
#14 0x000000000086b280 in do_target_wait (ecs=0x7ffc77c68eb0, options=...)
    at /home/vries/gdb_versions/devel/src/gdb/infrun.c:3814
#15 0x000000000086c04d in fetch_inferior_event ()
--Type <RET> for more, q to quit, c to continue without paging--
    at /home/vries/gdb_versions/devel/src/gdb/infrun.c:4172
#16 0x000000000084b13c in inferior_event_handler (event_type=INF_REG_EVENT)
    at /home/vries/gdb_versions/devel/src/gdb/inf-loop.c:41
#17 0x0000000000ab52c7 in remote_async_serial_handler (scb=0x3bc0460,
context=0x323b4d8)
    at /home/vries/gdb_versions/devel/src/gdb/remote.c:14424
#18 0x0000000000b5bff0 in run_async_handler_and_reschedule (scb=0x3bc0460)
    at /home/vries/gdb_versions/devel/src/gdb/ser-base.c:138
#19 0x0000000000b5c0d5 in fd_event (error=0, context=0x3bc0460)
    at /home/vries/gdb_versions/devel/src/gdb/ser-base.c:189
#20 0x000000000143544e in handle_file_event (file_ptr=0x3be2ec0, ready_mask=1)
    at /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:573
#21 0x00000000014359d6 in gdb_wait_for_event (block=1)
    at /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:694
#22 0x00000000014348aa in gdb_do_one_event (mstimeout=-1)
    at /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:264
#23 0x00000000008ffdbb in start_event_loop ()
    at /home/vries/gdb_versions/devel/src/gdb/main.c:411
#24 0x00000000008ffee1 in captured_command_loop ()
    at /home/vries/gdb_versions/devel/src/gdb/main.c:471
#25 0x0000000000901667 in captured_main (data=0x7ffc77c692b0)
--Type <RET> for more, q to quit, c to continue without paging--
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1310
#26 0x00000000009016cd in gdb_main (args=0x7ffc77c692b0)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1325
#27 0x000000000041a26e in main (argc=13, argv=0x7ffc77c693c8)
    at /home/vries/gdb_versions/devel/src/gdb/gdb.c:32
...

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
OK, I've tried another approach: set debug serial 1, in combination with:
...
+expect {
+    -i $server_spawn_id
+    -re "(.*)" {
+    }
+}
...
to drain the gdbserver output after each command.

Passing execution:
...
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug serial 1
monitor exit^M
[^M
w $][q][R][c][m][d][,][6][5][7][8][6][9][7][4][#][d][7][^M
r $][O][K][#][9][a](gdb) PASS: gdb.server/monitor-exit-quit.exp: monitor exit
set confirm off^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set confirm off
quit^M
[^M
w $][q][T][S][t][a][t][u][s][#][4][9][^M
r <Eof>]Remote connection closed^M
PASS: gdb.server/monitor-exit-quit.exp: quit
...

Failing execution:
...
(gdb) PASS: gdb.server/monitor-exit-quit.exp: set debug serial 1
monitor exit^M
[^M
w
$][q][R][c][m][d][,][6][5][7][8][6][9][7][4][#][d][7][fd13->timer-scheduled]^M
[^M
r $][O][K][#][9][fd13->fd-scheduled]^M
[a](gdb) PASS: gdb.server/monitor-exit-quit.exp: monitor exit
[fd13->timer-scheduled]^M
[<Eof>][fd13->synchronous]^M
Remote connection closed^M
(gdb) FAIL: gdb.server/monitor-exit-quit.exp: set confirm off
set confirm off^M
(gdb) quit^M
PASS: gdb.server/monitor-exit-quit.exp: quit
...

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14566
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14566&action=edit
Patch using "set debug serial 1"

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Another approach:
...
diff --git a/gdb/testsuite/gdb.server/monitor-exit-quit.exp
b/gdb/testsuite/gdb.server/moni
tor-exit-quit.exp
index 8fa41e3f07f..5fde1317cf5 100644
--- a/gdb/testsuite/gdb.server/monitor-exit-quit.exp
+++ b/gdb/testsuite/gdb.server/monitor-exit-quit.exp
@@ -36,9 +36,13 @@ save_vars { GDBFLAGS } {
        set GDBFLAGS "$GDBFLAGS -ex \"set sysroot\""
     }

-    clean_restart $binfile
+    clean_restart
 }

+gdb_test_no_output "set remotelogfile ~/gdb.serial.log"
+
+gdb_load $binfile
+
 # Make sure we're disconnected, in case we're testing with an
 # extended-remote board, therefore already connected.
 gdb_test "disconnect" ".*"
...

Passing version:
...
c monitor exit
w $qRcmd,65786974#d7
r $OK#9a
c set confirm off
c quit
w $qTStatus#49
r <Eof>
End of log
...

Failing version:
...
c monitor exit
w $qRcmd,65786974#d7
r $OK#9a<Eof>
End of log
...

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
I'm parking this, I'm stuck.  I can't get an easy reproducer and I don't
understand what's going on, which is not a good combination.

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
Hmm, with test-case gdb.threads/access-mem-running-thread-exit.exp and target
board native-gdbserver I run into:
...
(gdb) PASS: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access
mem
Remote debugging from host ::1, port 35770^M
monitor exit^M
(gdb) Remote connection closed^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...

That looks like the same symptom at least, and it reproduces sometimes when I
run the test-case by itself.

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

[Bug gdb/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #0)
> > I ran into:
> > ...
> > (gdb) monitor exit^M
> > (gdb) Remote connection closed^M
> > (gdb) FAIL: gdb.server/monitor-exit-quit.exp: monitor exit
> > ...
> 
> It's interesting though, we have:
> ...
> gdb_test_no_output "monitor exit"
> ...
> so given the point where the FAIL is produced, the gdb_test_no_output
> consumes two prompts.
> 
> So maybe this should be
> ...
> gdb_test_no_output -no-prompt-anchor "monitor exit"
> ...

And on that note, with read1 we have:
...
(gdb) monitor exit^M
(gdb) PASS: gdb.server/monitor-exit-quit.exp: monitor exit
Remote connection closed^M
(gdb) FAIL: gdb.server/monitor-exit-quit.exp: set confirm off
set confirm off^M
(gdb) FAIL: gdb.server/monitor-exit-quit.exp: quit (prompt)
 qupoitrt^M
 2mo41ni1^Mto
Rr emexotite ^M
debugging from host ::1, port 45844^M
Killing process(es): 28565^M
testcase /data/vries/gdb/src/gdb/testsuite/gdb.server/monitor-exit-quit.exp
completed in 1 seconds
...

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

[Bug testsuite/29833] [gdb] FAIL: gdb.server/monitor-exit-quit.exp: monitor exit

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |testsuite
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |15.1

--- Comment #15 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed by:
...
commit aae436c54a514d43ae66389f2ddbfed16ffdb725
Author: Simon Marchi <simon.marchi@efficios.com>
Date:   Mon Jan 15 16:23:42 2024 +0000

    gdb/testsuite: remove spurious $ in save_vars
...

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