CrashRpt: Difference between revisions

m
spelling
m (areipped-up -> are zipped)
m (spelling)
Line 10: Line 10:
</ref>
</ref>


If you experience a crash, please send a report using the dialog which appears - you can provide some additional info if you wish. Your log file, some system info (processor, time of day, Windows version, path to fgfs.exe) and a crash dump are zipped and sent to a server, and using some additional steps a real back-trace can be produced. (We need to write a privacy policy document for this, current the URL is a 404 - basically saying we promise not to do anything evil with the report info, although I’m not sure how much evil is possible since it’s the same info we ask for in a bug-report - I have switched off the options to include registry contents, and FGFS doesn’t touch the registry anyway) (For the curious, I’m not using Google Breakpad because it’s huge and seems somewhat inactive, instead I’m using CrashRpt which is very compact, completely open-source and new-BSD-licensed: https://code.google.com/p/crashrpt/ - although we do need to include a copy of their license.txt file somewhere in the installer) <ref> {{cite web
If you experience a crash, please send a report using the dialog which appears - you can provide some additional info if you wish. Your log file, some system info (processor, time of day, Windows version, path to fgfs.exe) and a crash dump are zipped and sent to a server. Using some additional steps a real back-trace can be produced. (We need to write a privacy policy document for this - currently the URL is a 404 - basically saying we promise not to do anything evil with the report info, although I’m not sure how much evil is possible since it’s the same info we ask for in a bug-report - I have switched off the options to include registry contents, and FGFS doesn’t touch the registry anyway) (For the curious, I’m not using Google Breakpad because it’s huge and seems somewhat inactive, instead I’m using CrashRpt which is very compact, completely open-source and new-BSD-licensed: https://code.google.com/p/crashrpt/ - although we do need to include a copy of their license.txt file somewhere in the installer) <ref> {{cite web
   | url    = http://sourceforge.net/p/flightgear/mailman/message/31877484/
   | url    = http://sourceforge.net/p/flightgear/mailman/message/31877484/
   | title  = <nowiki>[Flightgear-devel] Release candidates</nowiki>
   | title  = <nowiki>[Flightgear-devel] Release candidates</nowiki>
Line 26: Line 26:
</ref>
</ref>


Originally James only enabled CrashRpt for release builds, not nightlies, butit has been enabled since then. Also James explicity *disabled* the video capture support, because he felt the overhead of it would be too invasive when running FG, and the amount of video you’d need to record to make any difference to most crashes would be large.<ref> {{cite web
Originally James only enabled CrashRpt for release builds, not nightlies, but it has been enabled since then. Also James explicitly *disabled* the video capture support, because he felt the overhead of it would be too invasive when running FG, and the amount of video you’d need to record to make any difference to most crashes would be large.<ref> {{cite web
   | url    = http://sourceforge.net/p/flightgear/mailman/message/32621598/
   | url    = http://sourceforge.net/p/flightgear/mailman/message/32621598/
   | title  = <nowiki>Re: [Flightgear-devel] Win 64bit nightly is broken</nowiki>
   | title  = <nowiki>Re: [Flightgear-devel] Win 64bit nightly is broken</nowiki>
Line 36: Line 36:


== Help wanted ==
== Help wanted ==
There is one other Windows area Jamees could really use some help with - he added CrashRpt integration several releases ago and has a web server full of crash data.  
There is one other Windows area James could really use some help with - he added CrashRpt integration several releases ago and has a web server full of crash data.  


To make this useful someone with Windows skills needs to write some tooling to automaticly match a crash report to the archived PDB file and hence produce a usable back-trace.  
To make this useful someone with Windows skills needs to write some tooling to automatically match a crash report to the archived PDB file and hence produce a usable back-trace.  


We could then start analysing the most common sources of crashes.  
We could then start analyzing the most common sources of crashes.  
If that’s something you have any interest in, James can explain in more detail.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33628094/
If that’s something you have any interest in, James can explain in more detail.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33628094/
     |title=<nowiki>Re: [Flightgear-devel] SimGear/FlightGear Portability Patches</nowiki>
     |title=<nowiki>Re: [Flightgear-devel] SimGear/FlightGear Portability Patches</nowiki>
Line 57: Line 57:
</ref>
</ref>


the build-ID need to be matched to the debug symbols (.PDB) which the Jenkisn Windows build archives for releases. What’s missing as I said in the emails a long time ago, is the scripting to turn mini-dump + PDB files into a a backtrace with function names, if not line numbers. That would be a huge benefit. I’m happy to give anyone read access to my server to try this, and adjust where / how Jenkins archives the PDBs - but not being on Windows, my energy and ability to move this forward myself is very low. <ref>{{cite web
the build-ID need to be matched to the debug symbols (.PDB) which the Jenkins Windows build archives for releases. What’s missing as I said in the emails a long time ago, is the scripting to turn mini-dump + PDB files into a a back trace with function names, if not line numbers. That would be a huge benefit. I’m happy to give anyone read access to my server to try this, and adjust where / how Jenkins archives the PDBs - but not being on Windows, my energy and ability to move this forward myself is very low. <ref>{{cite web
   |url    = https://sourceforge.net/p/flightgear/mailman/message/35064086/
   |url    = https://sourceforge.net/p/flightgear/mailman/message/35064086/
   |title  = <nowiki>Re: [Flightgear-devel] Info on windows CrashRpts...</nowiki>
   |title  = <nowiki>Re: [Flightgear-devel] Info on windows CrashRpts...</nowiki>
Line 71: Line 71:
there are the following solutions:  
there are the following solutions:  
# get them from James' server and process them manually (e.g. via the script I mentioned in my previous e-mail, altered as necessary): pros: no changes in existing libraries/infrastructure, dumps remain private and accessible only to trusted developers; cons: Windows-only, some manual steps and script editing are needed;  
# get them from James' server and process them manually (e.g. via the script I mentioned in my previous e-mail, altered as necessary): pros: no changes in existing libraries/infrastructure, dumps remain private and accessible only to trusted developers; cons: Windows-only, some manual steps and script editing are needed;  
# use an automated solution like Dr Dump [1], which can be configured to accept CrashRpt reports; pros: only a small code change is needed, the service automatically analyes crash reports and groups them according to their stack traces (it is only needed to upload .pdb symbols); cons: Windows-only, possible privacy concerns (dumps might contain portions of memory storing personal data, and some people might not be comfortable with storing them on a third-party service);  
# use an automated solution like Dr Dump [1], which can be configured to accept CrashRpt reports; pros: only a small code change is needed, the service automatically analyzes crash reports and groups them according to their stack traces (it is only needed to upload .pdb symbols); cons: Windows-only, possible privacy concerns (dumps might contain portions of memory storing personal data, and some people might not be comfortable with storing them on a third-party service);  
# change the crash reporter to Google Breakpad [2]/Crashpad [3] and use an already developed frontend, like Socorro [4] or the Mini Breakpad Server [5], or some custom scripting; pros: cross-platform bug reports; cons: integrating Breakpad is not trivial (as well as huge [6]); Socorro is heavyweight (at least in my opinion).  
# change the crash reporter to Google Breakpad [2]/Crashpad [3] and use an already developed frontend, like Socorro [4] or the Mini Breakpad Server [5], or some custom scripting; pros: cross-platform bug reports; cons: integrating Breakpad is not trivial (as well as huge [6]); Socorro is heavyweight (at least in my opinion).  


Line 124: Line 124:


{{FGCquote
{{FGCquote
|1= people have been working on features to provide backtraces to developers without end-users having to be aware of the whole process, as in the whole crashrpt thing that Zakalawe implemented - but all this is still in its infancy unfortunately.  
|1= people have been working on features to provide back traces to developers without end-users having to be aware of the whole process, as in the whole crashrpt thing that Zakalawe implemented - but all this is still in its infancy unfortunately.  
Just keep in mind that FlightGear users are not dealing with a finished or "polished" product - things are very much in flux, and people can be part of the evolutionary process here.
Just keep in mind that FlightGear users are not dealing with a finished or "polished" product - things are very much in flux, and people can be part of the evolutionary process here.
|2= {{cite web
|2= {{cite web
185

edits