[Bug gdb/27908] New: FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[Bug gdb/27908] New: FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

            Bug ID: 27908
           Summary: FAIL: gdb.base/run-attach-while-running.exp:
                    threaded=1: run-or-attach=attach: non-stop=on: test:
                    attach to process (timeout)
           Product: gdb
           Version: 10.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 build gdb with -O2 -g (instead of the usual -O0 -g) and ran the testsuite.

With test-case gdb.base/run-attach-while-running.exp, I ran into:
...
FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach:
non-stop=on: test: attach to process (timeout)
...

In more detail:
...
(gdb) PASS: gdb.base/run-attach-while-running.exp: threaded=1:
run-or-attach=attach: non-stop=on: test: set confirm off
spawn
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/run-attach-while-running/run-attach-while-running-threads^M
attach 18201^M
Attaching to program:
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/run-attach-while-running/run-attach-while-running-threads,
process 18201^M
[New LWP 18206]^M
Reading symbols from /lib64/libpthread.so.0...^M
Reading symbols from
/usr/lib/debug/lib64/libpthread-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Reading symbols from /lib64/libm.so.6...^M
Reading symbols from
/usr/lib/debug/lib64/libm-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
Reading symbols from /lib64/libc.so.6...^M
Reading symbols from
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
Reading symbols from
/usr/lib/debug/lib64/ld-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
0x00007f13c85a74c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7ffc00aa0b60,
remaining=remaining@entry=0x7ffc00aa0b60) at
../sysdeps/unix/sysv/linux/nanosleep.c:27^M
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
(gdb) ^M
Thread 2 "run-attach-whil" stopped.^M
0x00007f13c85a74c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7f13c84dcea0,
remaining=remaining@entry=0x7f13c84dcea0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27^M
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach:
non-stop=on: test: attach to process (timeout)
killing 18201
Executing on build: kill -9 18201    (timeout = 300)
spawn -ignore SIGHUP kill -9 18201^M
closing exp24
waiting for exp24
testcase
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/run-attach-while-running.exp
completed in 23 seconds
...

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
The corresponding part in the test-case is:
...
    gdb_test_no_output "set confirm off"

    # Run again (or, connect to a new stub if using a stub), take               
    # advantage of the fact that runto_main leaves the breakpoint on            
    # main in place.                                                            
    if { ${run-or-attach} == "run" } {
      ...
    } elseif { ${run-or-attach} == "attach" } {
        set test_spawn_id [spawn_wait_for_attach $::binfile]
        set test_pid [spawn_id_get_pid $test_spawn_id]

        gdb_test "attach $test_pid" "Attaching to program: .*" "attach to
process"

        gdb_exit
        kill_wait_spawned_process $test_spawn_id
...

So, ISTM that the gdb_test doesn't consume the gdb prompt because it's followed
by more text:
...
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
(gdb) ^M
Thread 2 "run-attach-whil" stopped.^M
...

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Fails again in re-run, so this is reproducible.

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Rebuild at -O0, FAIL disappears:
...
(gdb) PASS: gdb.base/run-attach-while-running.exp: threaded=1:
run-or-attach=attach: non-stop=on: test: set confirm off
spawn
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/run-attach-while-running/run-attach-while-running-threads
attach 19181
Attaching to program:
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/run-attach-while-running/run-attach-while-running-threads,
process 19181
[New LWP 19186]
Reading symbols from /lib64/libpthread.so.0...
Reading symbols from
/usr/lib/debug/lib64/libpthread-2.26.so-2.26-lp152.26.6.1.x86_64.debug...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Reading symbols from /lib64/libm.so.6...
Reading symbols from
/usr/lib/debug/lib64/libm-2.26.so-2.26-lp152.26.6.1.x86_64.debug...
Reading symbols from /lib64/libc.so.6...
Reading symbols from
/usr/lib/debug/lib64/libc-2.26.so-2.26-lp152.26.6.1.x86_64.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from
/usr/lib/debug/lib64/ld-2.26.so-2.26-lp152.26.6.1.x86_64.debug...
0x00007fc68c5564c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7ffd3469cf00,
remaining=remaining@entry=0x7ffd3469cf00) at
../sysdeps/unix/sysv/linux/nanosleep.c:27
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
(gdb) PASS: gdb.base/run-attach-while-running.exp: threaded=1:
run-or-attach=attach: non-stop=on: test: attach to process
killing 19181
Executing on build: kill -9 19181    (timeout = 300)
spawn -ignore SIGHUP kill -9 19181
closing exp10
waiting for exp10
testcase
/home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/run-attach-while-running.exp
completed in 17 seconds
...

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Using this trick:
...
$ git diff
diff --git a/gdb/testsuite/gdb.base/run-attach-while-running.exp
b/gdb/testsuite/gdb.base/r
un-attach-while-running.exp
index 7c16aa6f5c4..230ad66ee73 100644
--- a/gdb/testsuite/gdb.base/run-attach-while-running.exp
+++ b/gdb/testsuite/gdb.base/run-attach-while-running.exp
@@ -93,6 +93,8 @@ proc_with_prefix test { non-stop threaded run-or-attach } {

        gdb_test "attach $test_pid" "Attaching to program: .*" "attach to
process"

+       gdb_test "echo bla\\n"
+
        gdb_exit
        kill_wait_spawned_process $test_spawn_id
     } else {
...
we can see the extra message in the PASS case as well:
...
Reading symbols from
/usr/lib/debug/lib64/ld-2.26.so-2.26-lp152.26.6.1.x86_64.debug...^M
0x00007f5eeb0554c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7fff7b78a1c0,
remaining=remaining@entry=0x7fff7b78a1c0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27^M
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
(gdb) PASS: gdb.base/run-attach-while-running.exp: threaded=1:
run-or-attach=attach: non-stop=on: test: attach to process
^M
Thread 2 "run-attach-whil" stopped.^M
0x00007f5eeb0554c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7f5eeaf8aea0,
remaining=remaining@entry=0x7f5eeaf8aea0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27^M
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
echo bla\n^M
bla^M
(gdb) PASS: gdb.base/run-attach-while-running.exp: threaded=1:
run-or-attach=attach: non-stop=on: test: echo bla\n
...

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

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

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

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
I put a breakpoint in fputs and continued to the point that the thread 2
message is printed:
...
(gdb) bt
#0  __GI__IO_fputs (str=0x17eda24 <get_print_cell()::buf+100> "2", 
    fp=0x7ffff51a35a0 <_IO_2_1_stdout_>) at iofputs.c:32
#1  0x0000000000b11d2d in stdio_file::puts (this=0x1a542e0, 
    linebuffer=0x17eda24 <get_print_cell()::buf+100> "2")
    at /home/vries/gdb_versions/devel/src/gdb/ui-file.c:247
#2  0x0000000000b4995f in fputs_maybe_filtered (
    linebuffer=0x17eda24 <get_print_cell()::buf+100> "2", stream=0x1a542e0,
filter=1)
    at /home/vries/gdb_versions/devel/src/gdb/utils.c:1731
#3  0x0000000000b49e3c in fputs_styled (
    linebuffer=0x17eda24 <get_print_cell()::buf+100> "2", style=...,
stream=0x1a542e0)
    at /home/vries/gdb_versions/devel/src/gdb/utils.c:1912
#4  0x000000000058b06b in cli_ui_out::do_field_string (this=0x1adce00, fldno=2,
width=0, 
    align=ui_noalign, fldname=0xf3a84d "thread-id", 
    string=0x17eda24 <get_print_cell()::buf+100> "2", style=...)
    at /home/vries/gdb_versions/devel/src/gdb/cli-out.c:177
#5  0x0000000000b131b0 in ui_out::field_string (this=0x1adce00, 
    fldname=0xf3a84d "thread-id", string=0x17eda24 <get_print_cell()::buf+100>
"2", 
    style=...) at /home/vries/gdb_versions/devel/src/gdb/ui-out.c:527
#6  0x00000000007c2a9e in print_signal_received_reason (uiout=0x1adce00, 
    siggnal=GDB_SIGNAL_0) at
/home/vries/gdb_versions/devel/src/gdb/infrun.c:8263
#7  0x0000000000af2fd6 in tui_on_signal_received (siggnal=GDB_SIGNAL_0)
    at /home/vries/gdb_versions/devel/src/gdb/tui/tui-interp.c:114
#8  0x000000000059fb6c in std::__invoke_impl<void, void (*&)(gdb_signal),
gdb_signal> (
    __f=@0x19eaaa0: 0xaf2f6c <tui_on_signal_received(gdb_signal)>)
    at /usr/include/c++/10/bits/invoke.h:60
#9  0x000000000059efd9 in std::__invoke_r<void, void (*&)(gdb_signal),
gdb_signal> (
    __fn=@0x19eaaa0: 0xaf2f6c <tui_on_signal_received(gdb_signal)>)
    at /usr/include/c++/10/bits/invoke.h:153
#10 0x000000000059ead6 in std::_Function_handler<void (gdb_signal), void
(*)(gdb_signal)>::_M_invoke(std::_Any_data const&, gdb_signal&&)
(__functor=..., 
    __args#0=@0x7fffffffd3a4: GDB_SIGNAL_0) at
/usr/include/c++/10/bits/std_function.h:291
#11 0x00000000007c80ee in std::function<void
(gdb_signal)>::operator()(gdb_signal) const (
    this=0x19eaaa0, __args#0=GDB_SIGNAL_0) at
/usr/include/c++/10/bits/std_function.h:622
#12 0x00000000007c75cd in gdb::observers::observable<gdb_signal>::notify (
    this=0x17c0b80 <gdb::observers::signal_received>, args#0=GDB_SIGNAL_0)
    at /home/vries/gdb_versions/devel/src/gdb/../gdbsupport/observable.h:150
#13 0x00000000007c3420 in normal_stop ()
    at /home/vries/gdb_versions/devel/src/gdb/infrun.c:8527
#14 0x00000000007b93b0 in fetch_inferior_event ()
    at /home/vries/gdb_versions/devel/src/gdb/infrun.c:4144
#15 0x000000000079d2a7 in inferior_event_handler (event_type=INF_REG_EVENT)
    at /home/vries/gdb_versions/devel/src/gdb/inf-loop.c:41
#16 0x00000000007c4eb4 in infrun_async_inferior_event_handler (data=0x0)
    at /home/vries/gdb_versions/devel/src/gdb/infrun.c:9423
#17 0x00000000004dc498 in check_async_event_handlers ()
    at /home/vries/gdb_versions/devel/src/gdb/async-event.c:335
#18 0x0000000000e1ea74 in gdb_do_one_event ()
    at /home/vries/gdb_versions/devel/src/gdbsupport/event-loop.cc:216
#19 0x00000000008292ba in start_event_loop ()
    at /home/vries/gdb_versions/devel/src/gdb/main.c:421
#20 0x00000000008293d9 in captured_command_loop ()
    at /home/vries/gdb_versions/devel/src/gdb/main.c:481
#21 0x000000000082abe4 in captured_main (data=0x7fffffffda30)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1353
#22 0x000000000082ac4a in gdb_main (args=0x7fffffffda30)
    at /home/vries/gdb_versions/devel/src/gdb/main.c:1368
#23 0x00000000004178dd in main (argc=12, argv=0x7fffffffdb38)
    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/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
So, at first glance the gdb behaviour looks incorrect to me.

If we're attaching in non-stop mode, shouldn't only thread 1 stop, and thread 2
keep running?

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Debugging setup using just an attach:
...
$ cat gdb.in
set non-stop on
set height 0
set width 0
set confirm off
$ cat ./exp.sh
#!/bin/sh

./outputs/gdb.base/run-attach-while-running/run-attach-while-running-threads &
pid=$!

cat gdb.in > gdb.cmd
echo attach $pid >> gdb.cmd
echo "info threads" >> gdb.cmd
./gdb -q -x gdb.cmd
...

Run exp.sh script and type info threads:
...
$ ./exp.sh
[New LWP 22236]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f3ff816c4c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7ffeb63936c0,
remaining=remaining@entry=0x7ffeb63936c0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
  Id   Target Id                                           Frame 
* 1    Thread 0x7f3ff8bab740 (LWP 22234) "run-attach-whil" 0x00007f3ff816c4c0
in __GI___nanosleep (requested_time=requested_time@entry=0x7ffeb63936c0,
remaining=remaining@entry=0x7ffeb63936c0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27
  2    Thread 0x7f3ff80a2700 (LWP 22236) "run-attach-whil" (running)
(gdb) 
Thread 2 "run-attach-whil" stopped.
0x00007f3ff816c4c0 in __GI___nanosleep
(requested_time=requested_time@entry=0x7f3ff80a1ea0,
remaining=remaining@entry=0x7f3ff80a1ea0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
info threads
  Id   Target Id                                           Frame 
* 1    Thread 0x7f3ff8bab740 (LWP 22234) "run-attach-whil" 0x00007f3ff816c4c0
in __GI___nanosleep (requested_time=requested_time@entry=0x7ffeb63936c0,
remaining=remaining@entry=0x7ffeb63936c0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27
  2    Thread 0x7f3ff80a2700 (LWP 22236) "run-attach-whil" 0x00007f3ff816c4c0
in __GI___nanosleep (requested_time=requested_time@entry=0x7f3ff80a1ea0,
remaining=remaining@entry=0x7f3ff80a1ea0) at
../sysdeps/unix/sysv/linux/nanosleep.c:27
(gdb) 
...

We can see that thread 2 initially is still running, then the thread stopped
message arrives, and then info threads shows that the thread is no longer
running.

So why did it stop?

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
Looks like a regression, passed at gdb-10-branch branchpoint.

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

[Bug gdb/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

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

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)
> Looks like a regression, passed at gdb-10-branch branchpoint.

Hmm, that bisects to:
...
commit 2ab76a181f3db93f051aaae66d65ff2733884d96
Author: Pedro Alves <pedro@palves.net>
Date:   Wed Dec 23 00:34:54 2020 +0000

    Fix attaching in non-stop mode (PR gdb/27055)
...

Looking in the test-case attach-non-stop.exp, it seems that the "thread
stopped" message is expected.

This makes no sense to me.   In non-stop mode, I'm expecting only one thread to
stop.  Why do we expect all threads to stop?  Isn't that all-stop mode
behaviour?

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

[Bug testsuite/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |testsuite

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #9)
> (In reply to Tom de Vries from comment #8)
> > Looks like a regression, passed at gdb-10-branch branchpoint.
> 
> Hmm, that bisects to:
> ...
> commit 2ab76a181f3db93f051aaae66d65ff2733884d96
> Author: Pedro Alves <pedro@palves.net>
> Date:   Wed Dec 23 00:34:54 2020 +0000
> 
>     Fix attaching in non-stop mode (PR gdb/27055)
> ...
> 
> Looking in the test-case attach-non-stop.exp, it seems that the "thread
> stopped" message is expected.
> 
> This makes no sense to me.   In non-stop mode, I'm expecting only one thread
> to stop.  Why do we expect all threads to stop?  Isn't that all-stop mode
> behaviour?

After rereading the documentation once more, I guess not.  The non-stop mode
only affects moments when "a thread stops to report a debugging event".  So, I
guess attaching is not a debugging event? I was not able to find a definition.

Anyway, I've submitted an RFC patch (
https://sourceware.org/pipermail/gdb-patches/2021-June/179615.html ) that
documents the behaviour of attach in non-stop mode, hopefully that will make
things a bit easier to understand.

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

[Bug testsuite/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b0e2f96b56b5bbddcd60ca87a0517a460d03dfb4

commit b0e2f96b56b5bbddcd60ca87a0517a460d03dfb4
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Jun 7 15:46:34 2021 +0200

    [gdb/testsuite] Fix gdb.base/run-attach-while-running.exp

    With a testsuite setup modified to make expect wait a little bit longer for
    gdb output (see PR27957), I reliably run into:
    ...
    27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
    (gdb) ^M
    Thread 2 "run-attach-whil" stopped.^M
    0x00007f13c85a74c0 in __GI___nanosleep () at nanosleep.c:27^M
    27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
    FAIL: gdb.base/run-attach-while-running.exp: threaded=1: \
      run-or-attach=attach: non-stop=on: test: attach to process (timeout)
    ...

    The problem is that we're trying to match the gdb_prompt using gdb_test
which
    uses '$gdb_prompt $'.  The terminating '$' prevents the match.

    Fix this by rewriting the gdb_test into a gdb_test_multiple and dropping
the
    '$'.

    Tested on x86_64-linux.

    gdb/testsuite/ChangeLog:

    2021-06-07  Tom de Vries  <tdevries@suse.de>

            PR testsuite/27908
            * gdb.base/run-attach-while-running.exp (test): Don't match prompt
            after attach using '$gdb_prompt $'.

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

[Bug testsuite/27908] FAIL: gdb.base/run-attach-while-running.exp: threaded=1: run-or-attach=attach: non-stop=on: test: attach to process (timeout)

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |11.1

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch fixing test-case committed, marking resolved-fixed.

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