On Tue, Sep 18, 2018 at 1:30 AM Randell Jesup <rjesup.n...@jesup.org> wrote:
> >On 9/17/2018 1:31 PM, Botond Ballo wrote: > >> One potential issue here is that an assertion failure in Nightly > >> builds might be simultaneously very annoying (because it crashes the > >> browser of Nightly users every time it occurs) and not very actionable > >> (because no reliable STR can be found for it). > > > >I would also be concerned about data loss and profile corruption when an > >assertion crashes the browser. I don't think we'll have a very easy time > >convincing people to do anything non-trivial with Nightly if there's a > >pretty good chance that they completely lose the fruits of their labour. > > > >I'd hope that this wouldn't be too frequent a problem, but it probably > >depends on the assertion, and the state of the durability of our user > >profiles. > > We already *need* to be stable in that case, given MOZ_RELEASE_ASSERT > (and normal just-because crashes). And as best I can tell, we are stable > (with regards to user profiles). Once upon a time we weren't (5(?) > years ago?) > I do come across MOZ_ASSERTs that trigger while browsing every once in a while (using a debug build). I almost never file bugs for these, because the issues are rarely reproducible, I often have little information that would be helpful as to how exactly the assertion was triggered, and I often am very actively working on something else and the assertion failure is just getting in the way of me getting my work done. I sometimes have to comment out a broken MOZ_ASSERT in my local build to be able to proceed. While it may be the case that we may need to be more stable for MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT in our codebase is actually a guaranteed to never fail, so promoting them all to be enabled in something like Nightly is extremely dangerous in terms of the stability of Nightly for users who are trying to use the browser to get their normal work done. This is, I believe, the way that we advertise Nightly these days: we advertise it as a mostly stable experimental version of Firefox and we encourage people to download it to try out the latest and greatest. Exposing that population to crashes as a result of promoting all MOZ_ASSERTs to become MOZ_RELEASE_ASSERTs seems like a proposition that needs to be backed by some data demonstrating that such a build would match the current stability requirements of Nightly. Note that with MOZ_DIAGNOSTIC_ASSERT, we have had tons of cases where people have put in assertions that were *surely* correct and would never ever fail, only to find out that the assertion turned out to be crashers and in some cases top crashers in Nightly. It is true that sometimes that is the only tool in our toolbox for hunting down bugs, but using a macro intentionally to opt in to such a scenario seems entirely different than promoting all of our existing assertions to Nightly without any way to assess their quality beforehand. FWIW, I think your original proposal, having a way to opt into assertions without a slow build locally, is extremely valuable. I could see myself using that option intentionally even with the pain points I described above, but for dogfooding rather than while working on a patch and such. Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
