The log file shows this:

looking at: Stack traces for SBProcess: pid = 832, state = stopped, threads = 2, executable = test_with_dwarf_and_attach_to_process_with_id_api
Stack trace for thread id=0x47c name=None queue=None stop reason=none
  frame #0: 0xffffffffffffffff ntdll.dll`DbgBreakPoint + 1

Stack trace for thread id=0xc68 name=None queue=None stop reason=none
  frame #0: 0x00000077908c2c None`None + -18446744071703589843



Expecting sub string: main.c:30
Not matched

FAIL

It is expecting to see the second thread stopped in main, but it is stopped somewhere else.  The address looks reasonable, so it is most likely that the main thread hasn't yet gotten through process initialization yet and it is still in loader initialization or CRT initialization.

Another possibility is that we just have a bug relating to multiple threads and the address is totally bogus.


We should fix the test suite to not rely on racy behavior like this by implementing a cross-platform is_debugger_present() function that all test inferiors can use so we can synchronize debugger behavior with test suite behavior, but to fix this completely we will always need to provide a way to skip the initial breakpoint so that we only hit the user-created breakpoint and not the loader breakpoint, guaranteeing that the code is in main.