I agree with Jason here, but I guess that's no surprise. Jim
> On Sep 12, 2017, at 2:57 PM, Jason Molenda via lldb-commits > <lldb-commits@lists.llvm.org> wrote: > > Or another way, I don't object to asserts because we hit them so often today. > I object to asserts in a shipping debugger fundamentally - it's not an error > mode we should encourage or depend on for an interactive tool. > >> On Sep 12, 2017, at 2:56 PM, Jason Molenda <jmole...@apple.com> wrote: >> >> I think debug-build asserts & more testing is something everyone can agree >> on. I don't want to speak for Greg, but I don't think anyone is going to >> sign on to the idea that the lldb source base becomes super well tested & >> bug free and then we start using asserts liberally. There are always going >> to be scenarios that our customers hit, with compilers we don't have access >> to, with programs we don't have access to, with targets we don't have access >> to, that we don't cover in our testsuite. We can work to expand our >> testsuite, and expand the scope of what / how we test the debugger, but >> we'll never match the behavior someone running lldb on an AutoCAD built with >> a three year old gcc or whatever. >> >>> On Sep 12, 2017, at 2:53 PM, Zachary Turner <ztur...@google.com> wrote: >>> >>> So let's say that in a hypothetical future we had very good test coverage. >>> Would there still be resistance to asserts? Because if your test coverage >>> is good, then your bots should be catching most stuff. >>> >>> On Tue, Sep 12, 2017 at 2:42 PM Greg Clayton <clayb...@gmail.com> wrote: >>> 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> wrote: >>>> >>>> >>>>> 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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
