[Lldb-commits] [lldb] Avoid expression evaluation in libStdC++ std::vector<bool> synthetic children provider (PR #108414)

[via lldb-commits]

jimingham wrote:

> > You are right, TryAllThreads defaults to True.
> > Not using TryAllThreads is actually dangerous in the general case. For instance, you can have the thread you run take a lock, then call some code that tries another lock that is held by a thread we aren't running. That times out so we cancel the execution evaluation but since we don't in general know about all the locking strategies available on any given platform, we don't know to unlock the first lock, and that will cause the program to deadlock later on if anybody tries to get the first lock again.
> > If you do the same thing with TryAllThreads set to true, then when the expression deadlocks on the running thread, we give a chance for the thread holding the second lock to release it, and the evaluation goes on to succeed, releasing the first lock on the way out.
> > Also, a very common workflow in debugging is to stop somewhere at a breakpoint, run a couple of expressions and continue, and you don't really care about the state of other threads. So true is the right default value.
> > There is an overload of CreateValueFromExpression that takes an EvaluteExpressionOptions, and if you are calling code internally you should be using that one because you really should think about how you want the expression to run.
> 
> Yeah, I see your point. VS debugger takes the other design decision to not run all threads, so it is notorious for expression evaluation causing IDE to deadlock or hang by accident during stepping. Eventually, they designed a UI to not automatically evaluate expressions in watch window during stop but has a "dangerous" button next to each expression saying click at your own risk.

The earliest dogfooding team for lldb - way back before it was public - was the clang team not surprisingly.  clang developers live by `dump()` so having a robust expression evaluator was one of the very early requirements!  BTW, in general I don't suggest having one of the hardest features to implement in your project be the first hard requirement...

https://github.com/llvm/llvm-project/pull/108414