Agreed. We need to do better on the test coverage part, don't think you'll get any pushback on that front.
> On Sep 12, 2017, at 2:36 PM, Zachary Turner <ztur...@google.com> wrote: > > Right, and the only reason it's a bigger problem is because of.... test > coverage. > > On Tue, Sep 12, 2017 at 2:34 PM Jason Molenda <jmole...@apple.com > <mailto:jmole...@apple.com>> wrote: > > > > On Sep 12, 2017, at 11:19 AM, Zachary Turner <ztur...@google.com > > <mailto:ztur...@google.com>> wrote: > > > > > > > > On Tue, Sep 12, 2017 at 11:07 AM Greg Clayton <clayb...@gmail.com > > <mailto:clayb...@gmail.com>> wrote: > > > >> On Sep 12, 2017, at 10:10 AM, Zachary Turner <ztur...@google.com > >> <mailto:ztur...@google.com>> wrote: > >> > >> > >> > >> On Tue, Sep 12, 2017 at 10:03 AM Greg Clayton <clayb...@gmail.com > >> <mailto:clayb...@gmail.com>> wrote: > >>> On Sep 12, 2017, at 9:53 AM, Zachary Turner <ztur...@google.com > >>> <mailto:ztur...@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 guess I'm speaking at someone who is supporting a debugger used by tens of > thousands of people. The debugger crashing is a vastly bigger problem to us > than bugs that didn't announce themselves by taking down the debugger. > lldb_asserts that activate when we're running debug builds are fine, that's > exactly when I want to see the debugger crash on my desktop or when it's > running the testsuite. Asserting when it's on the customer's desktop is a > no-go.
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
