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 experience that having the full story helps.. On Sun, Jul 3, 2016 at 8:50 AM, Alan Jeffrey <ajeff...@mozilla.com> wrote: > 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" <manishsm...@gmail.com> wrote: > > 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 PM, Alan Jeffrey <ajeff...@mozilla.com> wrote: > > > 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 > > channel errors, and hope that any channel error will have some other > error > > that gets reported. > > > > Alan. > > On Jul 3, 2016 01:10, "Manish Goregaokar" <manishsm...@gmail.com> wrote: > > > > > > 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 <j...@joshmatthews.net> > > 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 recent PR. This is not to say that > the > > >> stacks are incorrect in any way, merely that the panic reported is not > > >> guaranteed to be the first panic that occurred. This means that a > stack > > like > > >> the one in https://github.com/servo/servo/issues/12183 may appear to > be > > >> solved by the changes in https://github.com/servo/servo/pull/12030, > but > > that > > >> reported panic only occurred because some other thread panicked first. > > >> > > >> Unfortunately, this means that the triage process is less > > straightforward > > >> than we might otherwise hope. Please avoid the temptation to close > > issues > > >> referring to unwrapping error values from sending or receiving over > > channels > > >> without reproducing the issue yourself - these always indicate a > deeper > > >> problem that requires investigation first. > > >> > > >> Cheers, > > >> Josh > > >> _______________________________________________ > > >> dev-servo mailing list > > >> dev-servo@lists.mozilla.org > > >> https://lists.mozilla.org/listinfo/dev-servo > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
