<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hey,<br><br></div>so I managed to land the crash reporting that I presented during my FOSDEM talk finally in time for the 5.2 release. The code is already integrated and available for 5.2.0.0.beta1. Below are some information for all developers on how to make use of the crash reporting in the code and how to use the reported crashes.<br><br></div>Please note that you should not upload crashes from your own builds as there are no corresponding debug symbols on the server. Please only use it for official TDF builds.<br><br></div>* How does it work?<br><br></div>We use the breakpad library which registers signal handlers for a few signal that signal crashes and related problems (on Windows SEH exceptions).<br>During the start of Libreoffice we generate a file in the user profile called dump.ini with key value pairs of information (the URL of the server, the version, the product name). During the runtime of LibreOffice we may collect additional key value pairs, e.g. currently the used OpenGL device and driver if we use OpenGL. These information are all added to the dump.ini.<br> If we now hit a crash the crash handler will write a minidump of the current stack (a windows debug format) and add the path to the minidump file to the dump.ini. Nothing more is done from the crash reporting code in the crashing process (well you should not do more than really necessary in a process that might be corrupted).<br></div>During the next start-up we check if a dump.ini exists and if it contains a path to a minidump (if there is no such path we just ignore it), and if it exists ask the user if he wants to upload it.<br>Currently there is no feedback for the user with the ID or an URL for the uploaded crash.<br></div>The processing of the crash to a human readable stack trace happens completely on the server with the symbols generated during the build. To generate the symbols we have now two additional make targets (make symbols and make upload-symbols). Note that you can not use them to upload your own symbols as that is restricted to registered users.<br><br><br></div>* How can a developer make use of the crash reporting to provide more information?<br><br></div>I mentioned already that we already upload additional information with the crash report like the used OpenGL device and driver if we use them. This is done through the CrashReporter::AddKeyValue method from include/desktop/crashreport.hxx<br></div>The idea is that you can add important information as key value pairs and they will be available together with the crash report on the server. Some information that area already part of the minidump are the OS, the CPU, the loaded modules. Keep in mind that you should only collect the information that are really necessary.<br><br></div>Some information that we might want to select in the future:<br><br></div>OpenCL info if OpenCL is use<br>did we crash inside of our OpenGL code<br></div>loaded extensions<br><br></div><div>The plan is to improve the dialog asking the user to upload the crash with the information that we will include.<br><br><br></div><div>* How can a developer use the uploaded crashes to fix bugs?<br><br></div><div>The server side of our crash reporting is at <a href="http://crashreport.libreoffice.org/stats/" target="_blank">http://crashreport.libreoffice.org/stats/</a> (yes the main page is nearly unusable right now and incredibly ugly). But more importantly are pages like:<br><br><a href="http://crashreport.libreoffice.org/stats/version/5.2.0.0" target="_blank">http://crashreport.libreoffice.org/stats/version/5.2.0.0</a><br><a href="http://crashreport.libreoffice.org/stats/signature/sclo.dll+0x64396a" target="_blank">http://crashreport.libreoffice.org/stats/signature/sclo.dll+0x64396a</a><br><a href="http://crashreport.libreoffice.org/stats/crash_details/4a266638-29a6-41a9-bcec-cfccaffb1a6c" target="_blank">http://crashreport.libreoffice.org/stats/crash_details/4a266638-29a6-41a9-bcec-cfccaffb1a6c</a><br><br></div><div>Taking the last one as an example we have on the top all the meta information that are part of the minidump, below that the stacktrace of the crashing thread (the symbols for sclo.dll are missing because I rebuilt the library after generating the symbol information) and at the bottom a link to open the stack traces for all the other threads.<br></div><div>On the top you have 4 tabs for different information: the main details page, the metadata (which contains all the key-value pairs (empty in that case), the loaded modules and finally the raw export of the minidump.<br><br></div><div>Hopefully that provides enough information for you to understand the crash. In the future I also want to add a way to link crashes to bugzilla.<br><br><br></div><div>* Open Items<br><br></div><div>As can be seen we have a basic working concept but this is for now just a little bit more than a working prototype. We still need to make several big changes on client and server side. The following come to my mind:<br><br></div><div>** Client<br><br></div><div>better feedback for the user<br></div><div>collect all relevant and important information<br></div><div>clean-up my code<br></div><div>integrate it into the OSX build<br><br></div><div>** Server (code at <a href="https://github.com/mmohrhard/crash" target="_blank">https://github.com/mmohrhard/crash</a> )<br><br></div><div>more beautiful and somewhat useable pages and UX<br></div><div>automated a few workflows (currently the processing is async and needs to be done manually)<br></div><div>provide connection to bugzilla (see issue#9)<br></div><div>integrate windows library symbols (see issue#14)<br><br></div><div>many more smaller tasks, see for example other issues and TODO comments in the code<br><br><br></div><div>If you want to help out please talk to me. I'm especially looking for people with experience in web development around javascript, css and django.<br><br></div><div>Regards,<br></div><div>Markus<br></div><div><br></div></div>