jingham added a comment. One of the "frame recognizers" - probably the one that's causing this particular problem - is the "assert" recognizer. The idea is that when you call "assert" in user code, you pretty much always end up with a 4 or 5 frames deep stack that wanders it's way from assert to __pthread_kill. But you pretty much never care about any of those stack frames. The stack frame you really want to see is the caller of the assert. So the assert recognizer detects a thread in that situation and resets the selected frame to the assert caller.
So if you only applied recognizers on frames that stopped "with a reason", you would get into the situation where one thread stops because of a breakpoint, say, and gets a cooked presentation because it triggered a recognizer, but then you continue and another thread stops - say for another breakpoint. While you're stopped if you go back to look at the first thread you might see that, even though it had not made any progress, it's presentation was different. That's because it didn't have a stop reason and so didn't trigger the recognizer, but to a user, that's just going to be confusing. More generally, frame recognizers are about presenting stack frames in some way regardless of the reason why the thread stops. I don't want users to have to guess when they do and don't apply. So, first off, in situations which are highly sensitive to doing general work on "the stacks of all threads", you probably just want to turn frame recognizers off. To do that, call `frame recognizer clear`. Then none of this work will be done. But there are two other things to try if you want to keep these recognizers on. The first is to see if the recognizers can be run lazily when the user prints a thread backtrace. If you stop in the debugger because of a breakpoint, say, and the user never does a "thread list" and only backtraces the stopped thread, we should not pay the cost of running the recognizers on the other threads. It might take a little work to find/make a hook for "thread about to be presented to the user", but that would be a better place to put this computation. The other thing is that the way the assert frame recognizer is currently written it will always unwind 5 frames looking for the signature of an assert -> __pthread_kill (or whatever it is on other systems...). You could probably rewrite this to be more careful, and only continue unwinding if the first frame or two looked likely to lead to an assert. You're going to have to do this somewhat carefully, however, since you don't want to miss actual asserts. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103271/new/ https://reviews.llvm.org/D103271 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
