Just to comment on one aside from earlier, about the fact that Apple moved lldb out of process from Xcode. This was necessitated by some swift support issues, but it's true that the fact that lldb crashing no longer took down Xcode was a big plus to moving lldb out of process. This shouldn't be seen as a model to be emulated, but a shortcoming and failure of lldb as a mature piece of software. We can't provide this great debugger API that we encourage people to adopt and then say 'Well yeah sure but if you don't want your app crashing out from under you, better not use that'. Apple would have had to move lldb out of process regardless of this issue, but the fact that there had been discussions about moving lldb out of process BECAUSE of the crashing for a long time is a truth that pains me.
> On Sep 8, 2017, at 8:19 PM, Jason Molenda via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > > Also keep in mind that debug sessions have a tendency to be long lived. I > may be working through a problem for half an hour -- or this may be the one > rare instance where a bug reproduces -- and crashing because some bogus piece > of debug info that I don't care about is invalid is not acceptable. I've > gotten those bug reports, where someone has spent all day getting to just the > point where they have the problem in front of them, only to have the debugger > crash, and they are rightfully enraged at the debugger for this. > > An interactive tool like the debugger cannot use a model where asserting is > acceptable. Even if lldb is out-of-process, you're losing all of the work > you'd done until then, and complex bugs can involve extraordinarily long > running debug sessions. The fact that llvm/clang can assert out from under > us is to the detriment of lldb's quality. > > J > >> On Sep 8, 2017, at 7:41 PM, Jim Ingham via lldb-commits >> <lldb-commits@lists.llvm.org> wrote: >> >> Yes, the fact that llvm & clang and the MCJIT abort willy nilly has caused >> much pain to lldb. We don’t control that behavior and so are resigned to >> some continued suffering along those lines - though it seems like Lang is >> going to do a much cleaner job of handling problems in the new ORC JIT which >> will remove some significant source of that pain. And we have no intention >> of exacerbating it in areas we have more control over. That has been both >> Greg and my strong opinion since we started the work on lldb. Greg can >> weigh in on whether he has changed his mind about this, I have not. >> >> BTW, the fact that lldb can run out of process doesn’t make it that much >> better. Because lldb caches the parse of object files from debugger to >> debugger it is much more efficient to keep one out of process lldb session >> running per targeted OS. So Xcode runs one for all the Native processes and >> one for each iOS device. But that means that you are still going to take >> down all the debug sessions for that target when the debugger goes down. So >> still quite undesirable. >> >> Jim >> >> >>> On Sep 8, 2017, at 7:18 PM, Zachary Turner <ztur...@google.com> wrote: >>> >>> Note that if something originates from user input, then i agree there's no >>> excuse for a fail fast. But after all the inputs have been sanitized, I >>> think it's fine to fast fail >>> On Fri, Sep 8, 2017 at 7:12 PM Zachary Turner <ztur...@google.com> wrote: >>> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator >>> <revi...@reviews.llvm.org> wrote: >>> >>> I know there is debate about this one side and another but for lldb this is >>> a settled issue. Unless you really are in a state where the world is about >>> to come crashing down around you, you can't raise a fatal error in lldb. >>> And in this case, the world is only very minorly strange, so it is >>> certainly not appropriate. >>> >>> I don't agree that this is a settled issue in LLDB. >>> >>> For starters, clang already does this, and LLDB links against libclang. >>> >>> Second, a year or so ago, i recall Greg saying that LLDB now runs out of >>> process in Xcode, which should make this a non issue. >>> >>> Finally, by allowing inconsistent state to propagate through the code you >>> are only hurting yourself, as you're ultimately not preventing any crashes. >>> It'll just crash later when you de reference a null pointer or read some >>> corrupt memory. Furthermore, it actually increases the likelihood of >>> introducing bugs, due to the added complexity and technical debt introduced >>> by untested code paths >> >> _______________________________________________ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits > > _______________________________________________ > lldb-commits mailing list > lldb-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
