[lldb] lldb-dap stopping at __GI__dl_debug_state

[OCHyams]

We recently switched dexter (a tool in llvm that drives different debuggers to check debugging expectations) over to lldb-dap rather than the lldb python api. We've noticed tests being flaky since then on cross-project-tests-sie-ubuntu with intermittent failures across different tests.

In https://lab.llvm.org/buildbot/#/builders/181/builds/27634/steps/6/logs/FAIL__cross-project-tests__dex_step_function_cpp the test fails because lldb-dap reports back to dexter that we've stopped at function __GI__dl_debug_state (/build/glibc-B3wQXB/glibc-2.31/elf/dl-debug.c:73:1).

The test passes most runs, and is only sometimes seeing that. It seems like a deubgger implementation/internal breakpoint to me, but I'm not sure.

This raises some questions:
a) Is this expected?
b) Why does it only happen sometimes? (and why is this only an issue with lldb-dap, not with lldb? possibly our change coincided with an lldb change)
c) Is there something I can do to prevent lldb / lldb-dap telling me we've stopped there

Any pointers would be appreciated so that I can try to understand and prevent the flakiness.

[llvmbot]

@llvm/issue-subscribers-lldb-dap

Author: Orlando Cazalet-Hyams (OCHyams)

We recently switched dexter (a tool in llvm that drives different debuggers to check debugging expectations) over to lldb-dap rather than the lldb python api. We've noticed tests being flaky since then on [cross-project-tests-sie-ubuntu](https://lab.llvm.org/buildbot/#/builders/181) with intermittent failures across different tests.

In https://lab.llvm.org/buildbot/#/builders/181/builds/27634/steps/6/logs/FAIL__cross-project-tests__dex_step_function_cpp the test fails because lldb-dap reports back to dexter that we've stopped at function __GI__dl_debug_state (/build/glibc-B3wQXB/glibc-2.31/elf/dl-debug.c:73:1).

The test passes most runs, and is only sometimes seeing that. It seems like a deubgger implementation/internal breakpoint to me, but I'm not sure.

This raises some questions:
a) Is this expected?
b) Why does it only happen sometimes? (and why is this only an issue with lldb-dap, not with lldb? possibly our change coincided with an lldb change)
c) Is there something I can do to prevent lldb / lldb-dap telling me we've stopped there

Any pointers would be appreciated so that I can try to understand and prevent the flakiness.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: Orlando Cazalet-Hyams (OCHyams)

We recently switched dexter (a tool in llvm that drives different debuggers to check debugging expectations) over to lldb-dap rather than the lldb python api. We've noticed tests being flaky since then on [cross-project-tests-sie-ubuntu](https://lab.llvm.org/buildbot/#/builders/181) with intermittent failures across different tests.

In https://lab.llvm.org/buildbot/#/builders/181/builds/27634/steps/6/logs/FAIL__cross-project-tests__dex_step_function_cpp the test fails because lldb-dap reports back to dexter that we've stopped at function __GI__dl_debug_state (/build/glibc-B3wQXB/glibc-2.31/elf/dl-debug.c:73:1).

The test passes most runs, and is only sometimes seeing that. It seems like a deubgger implementation/internal breakpoint to me, but I'm not sure.

This raises some questions:
a) Is this expected?
b) Why does it only happen sometimes? (and why is this only an issue with lldb-dap, not with lldb? possibly our change coincided with an lldb change)
c) Is there something I can do to prevent lldb / lldb-dap telling me we've stopped there

Any pointers would be appreciated so that I can try to understand and prevent the flakiness.

[walter-erquinigo]

I think this is a bug. I'm sure this is an internal breakpoint and there's something in lldb core that is not autoresuming