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

[Jim Ingham via lldb-commits]

> On Sep 12, 2017, at 11:19 AM, Zachary Turner via lldb-commits <lldb-commits at lists.llvm.org> wrote:
> 
> 
> 
> On Tue, Sep 12, 2017 at 11:07 AM Greg Clayton <clayborg at gmail.com> wrote:
> 
>> On Sep 12, 2017, at 10:10 AM, Zachary Turner <zturner at google.com> wrote:
>> 
>> 
>> 
>> On Tue, Sep 12, 2017 at 10:03 AM Greg Clayton <clayborg at gmail.com> wrote:
>>> On Sep 12, 2017, at 9:53 AM, Zachary Turner <zturner at google.com> wrote:
>>> 
>>> If you had just logged it, the bug would still not be fixed because nobody would know about it.  I also can't believe we have to keep saying this :-/
>> 
>> By log, I mean Host::SystemLog(...) which would come out in the command line. Not "log enable ...". So users would see the issue and report the bug. Crashing doesn't mean people always report the bug.
>> I mentioned earlier in the thread that I assumed Xcode had an automatic crash that would handle the crash and automatically upload it to Apple.  Is this really not the case?  If core dumps are too big, why not just a stack trace?  Surely the Xcode team must have some kind of internal metrics system to track stability.
> 
> They do just upload text crash logs. It doesn't tell us what expression triggered the issue though. It shows a crash in an expression, but doesn't show the expression text as this violates privacy. 
> 
> So, you do get a bug report when a crash occurs then.  In contrast to the case where you simply log something, and don't get a crash report.
> 
> In some cases, you can look at the code and figure out why it crashed.  In other cases the bug occurs extremely infrequently (you can build heuristic matching of call-stacks into your infrastructure that processes the crash logs).  If it's a high incidence crasher then you do some investigation.  And the good news is, once you fix it, you've *actually* fixed it.  Now instead of hundreds of thousands of people using something that doesn't work quite right for presumably the rest of the software's life (since nobody knows about the bug), they have something that actually works.
> 
> There's probably some initial pain associated with this approach since the test coverage is so low right now (I came up with about ~25% code coverage in a test I ran a while back).  When you get this higher, your tests start catching all of the high incidence stuff, and then you're left with only occasional crashes.
> 
> And since you have the out of process stuff, it doesn't even bring down Xcode anymore.  Just a debugging session.  That's an amazing price to pay for having instant visibility into a huge class of bugs that LLDB is currently willfully ignoring.

I don't see any evidence for lldb suffering from "a huge class of bugs that we are willfully ignoring..." particularly ones that would be easily caught if we just had more asserts.  Can you give some examples?

From what I see (and I see all the bugs for lldb that come through the Apple reporting system which is where most of the people who use lldb on macOS/iOS/etc file them so I see lots of lldb bugs) we have a few big systemic issues.  The process event handling is racy somewhere - I've found a few places where this is true but not all yet.    And the synthetic child provider has memory management issue (though this seems to mostly effect Swift so not such an issue here.)  I'm not sure either of these would have been easier to find if we had a pervasive assert-based architecture.  Most of the other bugs are behavior problems - e.g. the name lookup in the expression parser doesn't mirror the order of lookup that would have happened in source code, so we find type names when we should find local variable names first, etc.  There are also not the sort of thing you can express in asserts.  They are the sort of thing that can be checked by testing, and when we fix bugs we always add test cases, so that coverage will increase over time.

Jim


> _______________________________________________
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits