Dealing with crash reports

[John Vivirito]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Farning wrote:
> How to deal with those darn crash reports?
> 
> I've included pitti, the apport dev, and slaw the bug dude in this
> conversation for their input.
> 
> Current status:
> The mozillateam is receiving unsymbolizied crash reports at a rate of
>> 10 per day.
> 
> In the unsymbolizied state the reports or not useful because of the lack
> of symbolized stacktrace. Issues title such as Random crash don't help.
> 
> We are responding to crash reports as follows
> 
> 
> 
> "Thank you for the bug report. Could you please install firefox-dbg
> (these are the firefox debugging symbols) and try to obtain a backtrace
> (or crash report) by following the instructions on
> https://wiki.ubuntu.com/MozillaTeam/Bugs 
> This will greatly aid us in tracking down your problem.
> 
> It is of particular interest that you run apport-retrace -d against your crash report before uploading.
> 
> Which flash package do you have installed?
> Which Java package do you have installed?
> Which firefox extensions do you have installed?"
> 
> 
> 
> 
> This is less than optimal because it is too difficult for a new user to perform and require re-uploading the report.
> We are getting a return <5% on these requests while anoying our users.
> 
> From a thread on dev-discuss I understand that pitti is working on setting up a service that will allow LP to symbolize the reports.
> 
> In the mean time what should we do?
> 1 Continue the request that user symbolize the reports.
>   pros
>     a few would be done
>   con
>     time and bandwidth intensive for users.
>     to be useful -dbg _must_ be installed for all packages touched in the stack just firefox... retrace -d is better here.
> 
> 2 Symbolize the reports ourselves.
>   pros
>     the job would get done...kind of
>   cons
>     very bandwidth and time intensive for triager.
>     -retrace -d must be run on a system with the same package versions as the reporter or you get version mismatch errors.
>  
> 3 Set unsymbolized reports as dupes of a master crash
>   pros 
>     cleans up the bug list until we have the proper tools to deal with
> them
>   cons
>     vile hack
> 
> 4  Delete unsymbolized reports after a period of time
>   pros 
>     cleans up the bug list
>   cons
>     really vile hack
> 
> Alexander, how much time will you be having to work on this issue over
> the next few weeks?  Is your focus going to be on cleaning up the
> variose packages?
> 
> 
> Martin, do you have an estimate on when the LP service will be in place. Would it be worth it too add an option to have
> apport run -retrace before uploading the crash report.  I understand you are already being flamed about apport being too 
> slow;(
> 
> 
> Thanks
> 
> How to deal with those darn crash reports?
> 
> I've included pitti, the apport dev, and slaw the bug dude in this
> conversation for their input.
> 
> Current status:
> The mozillateam is receiving unsymbolizied crash reports at a rate of
>> >10 per day.
> 
> In the unsymbolizied state the reports or not useful because of the lack
> of symbolized stacktrace. Issues title such as Random crash don't help.
> 
> We are responding to crash reports as follows
> 
> 
> 
> "Thank you for the bug report. Could you please install firefox-dbg
> (these are the firefox debugging symbols) and try to obtain a backtrace
> (or crash report) by following the instructions on
> https://wiki.ubuntu.com/MozillaTeam/Bugs 
> This will greatly aid us in tracking down your problem.
> 
> It is of particular interest that you run apport-retrace -d against your crash report before uploading.
> 
> Which flash package do you have installed?
> Which Java package do you have installed?
> Which firefox extensions do you have installed?"
> 
> 
> 
> 
> This is less than optimal because it is too difficult for a new user to perform and require re-uploading the report.
> We are getting a return <5% on these requests while anoying our users.
> 
> From a thread on dev-discuss I understand that pitti is working on setting up a service that will allow LP to symbolize the reports.
> 
> In the mean time what should we do?
> 1 Continue the request that user symbolize the reports.
>   pros
>     a few would be done
>   con
>     time and bandwidth intensive for users.
>     to be useful -dbg _must_ be installed for all packages touched in the stack just firefox... retrace -d is better here.
> 
> 2 Symbolize the reports ourselves.
>   pros
>     the job would get done...kind of
>   cons
>     very bandwidth and time intensive for triager.
>     -retrace -d must be run on a system with the same package versions as the reporter or you get version mismatch errors.
>  
> 3 Set unsymbolized reports as dupes of a master crash
>   pros 
>     cleans up the bug list until we have the proper tools to deal with
> them
>   cons
>     vile hack
> 
> 4  Delete unsymbolized reports after a period of time
>   pros 
>     cleans up the bug list
>   cons
>     really vile hack
> 
> Alexander, how much time will you be having to work on this issue over
> the next few weeks?  Is your focus going to be on cleaning up the
> variose packages?
> 
> 
> Martin, do you have an estimate on when the LP service will be in place. Would it be worth it too add an option to have
> apport run -retrace before uploading the crash report.  I understand you are already being flamed about apport being too 
> slow;(
> 
> 
> Thanks
> -- David Farning <dfarning at gmail.com>
> 
> 
> 
> -- Ubuntu-mozillateam mailing list Ubuntu-mozillateam at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-mozillateam 

As it stands me and another member of the team are running retraces on
bugs. seems to be going fairly well. there are some bugs that we dont
have -dbg packages for. there are -dbgsym packages for alot of them but
pitti already knows about the repo needing updating. we do need -dbgsym
for edgy and thunderbird also i ran a few retraces on TB and they are a
bit slim with symbols.Running apport-retrace -d will not work on firefox
bugs because of the lack of dbgsym. right now the only way to do it is
apport-retrace <file> that i found usful. once retrace is done i cat
file | less and look to see if everything is there and than i upload the
stacktrace and sometimes the threadstacktrace when i have one. Pitti is
also aware of errors we get on firefox bugs. when we retrace it and
removes everything after stacktrace.
- --
Thanks,
GnomeFreak

https://wiki.ubuntu.com/JohnVivirito
https://launchpad.net/people/gnomefreak
http://freewebs.com/ubuntufreak
Linux User# 414246
Ubuntu User# 8175

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFzezhqig4QTwcPCoRAhGQAJ9EFG4q0LvVbDqFf1r7ynFWGJnwQgCfXfks
8vaIk96Oe6Q8cdLnwxYguE8=
=6aAW
-----END PGP SIGNATURE-----