Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[lldb] lldb-dap fail to load libc.so.6 symbols (in time?) #158311

@OCHyams

Description

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

Once issue we have seen is that tests will intermittently fail to load libc.so.6 symbols. The dap logs in a passing test get this event that a failling test doesn't see:

<- {
  "body": {
    "module": {
      "addressRange": "0x7ffff7dd1000",
      "debugInfoSize": "4.9MB",
      "id": "5792732F-7831-58C6-6FB4-F3756458CA24-E46E827D",
      "name": "libc.so.6",
      "path": "/lib/x86_64-linux-gnu/libc.so.6",
      "symbolFilePath": "/usr/lib/debug/.build-id/57/92732f783158c66fb4f3756458ca24e46e827d.debug",
      "symbolStatus": "Symbols loaded."
    },
    "reason": "new"
  },
  "event": "module",
  "seq": 0,
  "type": "event"
}

What could cause this, and why might it only be happening sometimes? My naïve assumption is that they just don't load in time, but I have no idea whether that's true.

We saw intermittent failures because dexter wasn't expecting to get missing stackFrame source paths which were sometimes observed stepping out of main as a result of the missing symbols. We've fixed that, but it would be good to understand whether this is intended behaviour, and if it is, whether there's some way to indicate to lldb through lldb-dap that we would rather wait for all symbols to be loaded rather than step without source.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions