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

[Pedro Alves <pedro@palves.net>]

On 2026-05-08 19:43, Tom Tromey wrote:

> As mentioned elsewhere, this caused some regressions in the internal
> AdaCore test suite.

Thanks.

> 
> 
> On x86 Windows 2019 we see the "unwaited-for children" message
> 
>     (gdb) run my_which2
>     Starting program: C:\it\sbx\wave\x86-windows\gdb_version-head_test\tmp\test\gdb-TS-8qgi1zlz\K509-012__path_cmd\my_which.exe my_which2
>     C:\it\sbx\wave\x86-windows\gdb_version-head_test\tmp\test\gdb-TS-8qgi1zlz\K509-012__path_cmd\mybin2\my_which2.exe
>     No unwaited-for children left.
>     FAILED:K509-012__path_cmd:run my_which2
> 
> A few tests seem to fail this way but they are all pretty basic things
> like the above.

That sounds like the same symptom of the problem you saw last year, though I
think it was another test back then.

> 
> The same happens on x86-64 Windows 2019.
> 
> 
> 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.

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'm not really sure that the Windows 2019 detail is completely relevant
> because that seems to be the only version of the OS that we're using to
> test gdb HEAD.

What was the other system that you ran tests on, where they passed?

I don't have a Windows 2019 machine handy.  I've been testing on Windows 11
with latest Microsoft updates.

> 
> Anyway I am happy to produce logs or something if that would help.
> Eventually I'll probably end up debugging this myself but it might be a
> while.

Reducing things to something that I could reproduce myself would help a lot.
We already tried that last year, and the tests I came up with that mimicked
yours didn't trigger the issues for me, unfortunately.  I don't think we ever
confirmed if my tests would trigger the problems for you, though.

Confirming that "maint show target-non-stop" says non-stop is on, and
checking whether "maint set target-non-stop off" makes a difference might help.

"set debug infrun 1" + the usual "set debugfoo 1" Windows target logs are probably
helpful.

Pedro Alves