> On Sep 12, 2017, at 11:19 AM, Zachary Turner <ztur...@google.com> wrote: > > > > On Tue, Sep 12, 2017 at 11:07 AM Greg Clayton <clayb...@gmail.com> wrote: > >> On Sep 12, 2017, at 10:10 AM, Zachary Turner <ztur...@google.com> wrote: >> >> >> >> On Tue, Sep 12, 2017 at 10:03 AM Greg Clayton <clayb...@gmail.com> wrote: >>> On Sep 12, 2017, at 9:53 AM, Zachary Turner <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
