[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)

Jim Ingham via lldb-commits lldb-commits at lists.llvm.org
Fri Sep 8 19:41:00 PDT 2017

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.


> On Sep 8, 2017, at 7:18 PM, Zachary Turner <zturner at 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 <zturner at google.com <mailto:zturner at google.com>> wrote:
> On Fri, Sep 8, 2017 at 6:11 PM Jim Ingham via Phabricator <reviews at reviews.llvm.org <mailto:reviews at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170908/705afad3/attachment.html>

More information about the lldb-commits mailing list