And for the record, I *do* get where your concern comes from. It comes from the fact that even if you crash, as I'm suggesting, you still won't know about it until it's too late (i.e. in the wild).
That of course goes back to my constant hounding on having more tests. If you have more tests, you would catch it much earlier. "Hide bugs and try to pretend they didn't happen" is *very obviously* worse than "catch bugs immediately and fix them". What that means is that someone might have to spend months, or even years, doing nothing but re-designing things to be more testable, and re-designing the test infrastructure to make the overhead of writing a test much lower. Alternatively, do nothing, and continue having thousands of latent bugs that annoy users and lead to death by 1000 cuts. Which is, as I said earlier, an existential threat to the project. On Tue, 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 :-/ > > On Tue, Sep 12, 2017 at 9:50 AM Greg Clayton <clayb...@gmail.com> wrote: > >> Success? No. Log something. Return an error. Anything but crashing. >> Crashing is not acceptable. I can't believe we have to keep saying this. >> >> On Sep 11, 2017, at 4:39 PM, Zachary Turner via lldb-commits < >> lldb-commits@lists.llvm.org> wrote: >> >> >> >> On Mon, Sep 11, 2017 at 4:22 PM Jason Molenda via lldb-commits < >> lldb-commits@lists.llvm.org> wrote: >> >>> fwiw the reason the JIT came up is because we had an instance where the >>> older MCJIT wasn't handling a relocation in thumb code about six weeks ago >>> and we only caught the crash a couple days before we released a beta of >>> it. It definitely can happen with MCJIT. I think with ORC JIT this is a >>> not going to be a problem -- but it's a good example of a class of problem >>> where the subsystem (jit) considers the failure catastrophic, whereas the >>> user will find another way to do their work. When it takes the developer >>> an hour to get to the point of failure, they try to print a variable, lldb >>> ingests a ton of debug info and then we crash because some little detail >>> was not valid, or they try to run an expression and the debugger crashes >>> with an unsupported relocation, I can't overstate what an enormous failure >>> of the debugger that is. >>> >> >> I disagree. It sounds like a success. As a result of it crashing six >> weeks ago, you learned the bug exists, and now Lang has fixed it. >> >> _______________________________________________ >> 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
