Re: [dev-servo] Stacks reported in automated panic reports cannot be trusted
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" 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 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
Re: [dev-servo] Stacks reported in automated panic reports cannot be trusted
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 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" 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 > 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
Re: [dev-servo] Stacks reported in automated panic reports cannot be trusted
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 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 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" 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 > 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
