To do that, we'd have to add some delay into sending the crash report, e.g.
generate the report a second after the first panic. My concern about doing
this is just an issue of adding code complexity and brittleness to the
constellation, which is our single point of failure.
On Jul 6, 2016 07:05, "J
Would it not be feasible to retain *all* the panic stacks? That is, the
original panic stack; the stacks for the channel operations that
subsequently failed because the other end had been dropped; and so on?
Unless one has a reason one must throw away information about a crash, it's
always been my
There's already a PR to buffer up warnings for inclusion in the crash
report. Once that lands, it should be pretty easy to put warnings in for
channel errors rather than panics.
On Jul 3, 2016 10:45, "Manish Goregaokar" wrote:
Right. I think we should do both -- Servo should report these errors i
Right. I think we should do both -- Servo should report these errors in a
truncated form (single line with error contents and location), and bhtml
can either filter these out or include them in the error reporting box
until it gets a real backtrace
-Manish Goregaokar
On Sun, Jul 3, 2016 at 9:11 P
The problem is the messages can arrive to the constellation out of order.
The constellation passes then on to browser.html, which I believe just
reports the first one. We could try to be cleverer than that and batch them
up, and wait before reporting. Or, as Manish suggested, we could filter out
ch
At one point we were silencing MPSC and IPC errors so that the main backtrace
is the only thing you see. Perhaps we should do that again?
dev-servo@lists.mozilla.org wrote:
> Is it possible to get the correct stack somehow?
>
> jack.
>
> On Sat, Jul 2, 2016 at 3:33 PM, Josh Matthews wrote:
>>
Is it possible to get the correct stack somehow?
jack.
On Sat, Jul 2, 2016 at 3:33 PM, Josh Matthews wrote:
> Hi everyone! To my dismay, I have realized that the stack traces for
> automated crash reports cannot be trusted for the purposes of marking issues
> as duplicates or fixed by a more rec
Hi everyone! To my dismay, I have realized that the stack traces for
automated crash reports cannot be trusted for the purposes of marking
issues as duplicates or fixed by a more recent PR. This is not to say
that the stacks are incorrect in any way, merely that the panic reported
is not guaran
8 matches
Mail list logo
