[Lldb-commits] [PATCH] D37651: Fix for bug 34532 - A few rough corners related to post-mortem debugging (core/minidump)
Zachary Turner via lldb-commits
lldb-commits at lists.llvm.org
Tue Sep 12 14:36:42 PDT 2017
Right, and the only reason it's a bigger problem is because of.... test
On Tue, Sep 12, 2017 at 2:34 PM Jason Molenda <jmolenda at apple.com> wrote:
> > On Sep 12, 2017, at 11:19 AM, Zachary Turner <zturner at google.com> wrote:
> > On Tue, Sep 12, 2017 at 11:07 AM Greg Clayton <clayborg at gmail.com>
> >> On Sep 12, 2017, at 10:10 AM, Zachary Turner <zturner at google.com>
> >> On Tue, Sep 12, 2017 at 10:03 AM Greg Clayton <clayborg at gmail.com>
> >>> On Sep 12, 2017, at 9:53 AM, Zachary Turner <zturner at google.com>
> >>> 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits