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, "Jim Blandy" <jbla...@mozilla.com> wrote:
> 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 > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
