On Mon, Sep 24, 2018 at 04:05:22PM -0400, Randell Jesup wrote:
On 9/20/18 5:59 PM, Andrew McCreight wrote:
On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote:
On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
So, I don't think we need to do anything fancy with forking - we'd
>On 9/20/18 5:59 PM, Andrew McCreight wrote:
>> On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote:
>>
>>> On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via
On 9/20/18 5:59 PM, Andrew McCreight wrote:
On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote:
On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via telemetry rather
Cameron McCormack writes:
> (I wonder if we could collect all the same data, and use the same
> crash reporting infrastructure, for non-crashing crash reports like
> this.)
For what it's worth, I've done something very close to this
*accidentally*, on Linux, by manually sending a crash signal
On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione wrote:
> On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
> >So, I don't think we need to do anything fancy with forking - we'd just
> >need to capture stacks and send them via telemetry rather than as a crash
> >report. This was the
On Wed, Sep 19, 2018 at 8:38 PM Bobby Holley wrote:
> I spoke with Georg about it recently, and got the impression that his team
> could get it finished if we had a current use-case. Hooking it up to
> MOZ_ASSERTs on nightly builds seems like a pretty good one.
>
That would indeed be wonderful
On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via telemetry rather than as a crash
report. This was the idea behind bug 1209131, which got pretty far along
but never made
So, I don't think we need to do anything fancy with forking - we'd just
need to capture stacks and send them via telemetry rather than as a crash
report. This was the idea behind bug 1209131, which got pretty far along
but never made it to the finish line.
I spoke with Georg about it recently,
>On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote:
>> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
>> > 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
On 9/19/2018 5:30 PM, Mike Hommey wrote:
On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child,
and continue in the parent process.
There is kind of a way to do this on Windows 8.1+ too if we wanted [1],
though it obviously doesn't quite work the same way.
[1]
On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote:
> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
> > 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
On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
> 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
Ehsan wrote:
>On Tue, Sep 18, 2018 at 1:30 AM Randell Jesup wrote:
>> 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
On Wed, Sep 19, 2018 at 11:52:07AM -0400, Ehsan Akhgari wrote:
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
On Tue, Sep 18, 2018 at 1:30 AM Randell Jesup 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)
>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
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).
With webrender we've had pretty good results from always defaulting to
MOZ_RELEASE_ASSERT, as users are often mildly decent at producing an STR.
But perhaps we're luckier in that everyone dogfooding webrender was more
willing to figure things out than a nightly user?
On Mon, Sep 17, 2018 at 3:31
On 9/17/18 3:25 PM, Jeff Gilbert wrote:
I would be excited for something between MOZ_ASSERT and MOZ_CRASH
Note that we already have MOZ_DIAGNOSTIC_ASSERT in between those. We
should perhaps be using it a bit more.
-Boris
___
dev-platform mailing
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). That's the situation
I'm in with bug 1457603,
I would be excited for something between MOZ_ASSERT and MOZ_CRASH, but
I think raising MOZ_ASSERTs to MOZ_ASSERT_NIGHTLY should be done by
hand and reviewed.
On Mon, Sep 17, 2018 at 11:46 AM, Kris Maglione wrote:
> There are some non-trivial snags for this proposal. A lot of assertions rely
> on
There are some non-trivial snags for this proposal. A lot of
assertions rely on other code gated on #ifdef DEBUG or
DebugOnly<...> to avoid defining data members or storing values
in non-debug builds. We could replace those with more
fine-grained macros, of course, but particularly in the case
It may be possible to narrow down the performance-regressing MOZ_ASSERTs
by pushing a series of Talos try runs with MOZ_ASSERT enabled for
specific top-level directories - then take those with significant
regressions, and recurse down a layer, lather, rinse, repeat to at least
the leaf-dir level,
23 matches
Mail list logo
