Re: [PATCH v3 00/11] Windows non-stop mode

[Pedro Alves <pedro@palves.net>]

Hi!

On 2026-05-08 22:27, Pedro Alves wrote:
> On 2026-05-08 19:43, Tom Tromey wrote:
>> There's another test that adds some event listeners from Python like:
>>
>>         gdb.events.stop.connect(signal_stop_handler)
>>         gdb.events.stop.connect(breakpoint_stop_handler)
>>         gdb.events.exited.connect(exit_handler)
>>         gdb.events.cont.connect(continue_handler)
>>
>> These just print what happens.  The test started failing because what
>> exactly happens has changed:
>>
>>      --- Regression: K224-002__py-events:what_happened
>>      - Could not match
>>          event type: continue
>>          event type: stop
>>          event  !! FAILS HERE -> type: stop
>>          stop reason: breakpoint
>>          breakpoint number: @NUMBER
>>          all threads stopped
>>      - Against input line
>>          event type: continue
>>          event type: continue
>>          event type: stop
>>          event type: stop
>>          stop reason: breakpoint
>>          breakpoint number: 2
>>          all threads stopped
>>
>> That is, two stop events seem to be produced?
>>
> 
> I'm afraid I'm not able to parse the output above off hand.
> 
>> According to the notes this test is a port of gdb.python/py-events.exp,
>> though I am not sure if they have diverged.
> 

I was looking at the output of gdb.python/py-events.exp on Linux, and I see two stop events there:

 Breakpoint 2, first () at /home/pedro/rocm/gdb/src/gdb/testsuite/gdb.python/py-events.c:30
 30        for (i = 0; i < 2; i++)
 event type: stop
 event type: stop
 stop reason: breakpoint
 first breakpoint number: 2
 breakpoint number: 2
 breakpoint number: 3
 all threads stopped
 (gdb) PASS: gdb.python/py-events.exp: continue

Two stops seems to be what happens for every test in that testcase.  I noticed that the .exp file
matches with:

 # Test continue event and breakpoint stop event
 gdb_test "continue" ".*event type: continue.*
 .*event type: stop.*
 .*stop reason: breakpoint.*
 .*first breakpoint number: 2.*
 .*breakpoint number: 2.*
 .*breakpoint number: 3.*
 all threads stopped.*"

So if gdb prints two stop events by mistake, the testcase will still pass.

I went as further back as commit f1cc4f02cb558d513cb4575211dbbb690391618f (May 21 2023), and I saw
the same there, though.

Looking at gdb.python/-events.py, we have:

    def invoke(self, arg, from_tty):
        gdb.events.stop.connect(signal_stop_handler)
        gdb.events.stop.connect(breakpoint_stop_handler)

So we register two callbacks for the same event, so it's really expected.  With:

 diff --git i/gdb/testsuite/gdb.python/py-events.py w/gdb/testsuite/gdb.python/py-events.py
 index 2cb48e4eccf..a5ac083bfd4 100644
 --- i/gdb/testsuite/gdb.python/py-events.py
 +++ w/gdb/testsuite/gdb.python/py-events.py
 @@ -20,7 +20,7 @@ import gdb
 
  def signal_stop_handler(event):
      if isinstance(event, gdb.StopEvent):
 -        print("event type: stop")
 +        print("event type: stop (1)")
      if isinstance(event, gdb.SignalEvent):
          print("stop reason: signal")
          print("stop signal: %s" % (event.stop_signal))
 @@ -30,7 +30,7 @@ def signal_stop_handler(event):
  
  def breakpoint_stop_handler(event):
      if isinstance(event, gdb.StopEvent):
 -        print("event type: stop")
 +        print("event type: stop (2)")

I see:

 Breakpoint 2, first () at /home/pedro/rocm/gdb/src/gdb/testsuite/gdb.python/py-events.c:30
 30        for (i = 0; i < 2; i++)
 event type: stop (1)
 event type: stop (2)
 stop reason: breakpoint

So that seems totally expected, at least for gdb.python/py-events.exp.

I don't suppose that somehow your internal testcase does the same and somehow that
wasn't noticed before?

> Hmm, I'm cross compiling Cygwin gdb and that doesn't include Python support.
> I'll see if I can set things up to enable Python support and run
> gdb.python/py-events.exp with Cygwin.
> 

I managed to do this.  That exposed a number of pre-existing problems, as usual...

All fixed with this series:

  https://inbox.sourceware.org/gdb-patches/20260522001626.393908-1-pedro@palves.net/T/

Nothing related to the non-stop support, though.

Pedro Alves