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

[Tom Tromey <tromey@adacore.com>]

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> Here is the third iteration of the Windows non-stop work.

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


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.

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?

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'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.

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.

thanks,
Tom