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

[Zachary Turner via lldb-commits]

On Fri, Sep 8, 2017 at 8:19 PM Jason Molenda <jmolenda at apple.com> wrote:

> Also keep in mind that debug sessions have a tendency to be long lived.  I
> may be working through a problem for half an hour -- or this may be the one
> rare instance where a bug reproduces -- and crashing because some bogus
> piece of debug info that I don't care about is invalid is not acceptable.
> I've gotten those bug reports, where someone has spent all day getting to
> just the point where they have the problem in front of them, only to have
> the debugger crash, and they are rightfully enraged at the debugger for
> this.
>
> An interactive tool like the debugger cannot use a model where asserting
> is acceptable.  Even if lldb is out-of-process, you're losing all of the
> work you'd done until then, and complex bugs can involve extraordinarily
> long running debug sessions.  The fact that llvm/clang can assert out from
> under us is to the detriment of lldb's quality.
>
> J

Fwiw i think we all agree that it shouldn't crash.  What we disagree on is
the best way of making it crash less.  It's easy to see why someone would
argue that adding an assert increases the incidence of crashes.  I mean on
the surface it seems ridiculous to argue otherwise.

But otherwise is precisely what we all continue to argue.

Your position is that by going out of your way to avoid crashes, it will
crash less and be more stable.  Pretty intuitive position if I'm being
honest.  But I don't agree.

I think you are trading short term metrics for long term technical debt.

You fix one crash by adding a null check, without figuring out why null
ever got in there in the first place.

You get fewer bug reports because instead of crashing, which would
hopefully trigger some automatic crash uploader in Xcode that automatically
files a rdar, you just never find out about the bug in the first place.

You introduce even more bugs, because when you go to edit a function, its
complexity and branching is through the roof, and you overlook something
some corner case.

You have less test coverage because you introduce another untested branch
in the code, reducing the already abysmal code coverage even further.

The way to reduce crashing is to *increase* the code coverage of your test
suite.  That is the solution.  And you don't do that by adding null checks
everywhere, you do it by removing them and asserting.

Yes, it means Xcode might crash.  But you know the bug exists!  How many
bugs are out there right now that nobody even knows about because they are
hidden by a null pointer check and instead of the user trying to figure out
what's going and filing a bug report, they just give up and use gdb
instead.  That's one more person you're never going to get back.

Crashing Xcode is annoying, but it's fixable.  But when your technical debt
is going up and to the right, and your test coverage is going down and to
the right, that's an existential threat to the project .

Btw, i still don't understand why asserts cause anything to crash, given
that they're supposed to be turned off in a release build
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20170909/1a49fd4d/attachment.html>