-
Notifications
You must be signed in to change notification settings - Fork 15k
Description
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
path
s 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.