Differences between revisions 7 and 8
Revision 7 as of 2015-04-28 19:04:25
Size: 7320
Editor: ?Yuru Shao
Revision 8 as of 2015-04-29 13:58:26
Size: 2810
Editor: ?Yuru Shao
Deletions are marked like this. Additions are marked like this.
Line 24: Line 24:

=== Student's Proposal ===

=== 1. Ideas ===
Based on project description and my preliminary investigations, as well as my discussion with the mentor, I have three concrete ideas.

==== 1.1 Crash Signature ====

Apport is able to parse core dumps into crash files (with the .crash extension), which provide us rich information regarding each crash, including stack trace, process map, disassembly, and so on. Apport generates crash reports on the basis of crash files and uploads them to the server. However, both crash files and crash reports are not comparable. That means we cannot know the similarity between two reports, resulting in possible duplicate.

To address this, we can generate a signature from the crash file for each program crash. Here the signature should not contain any machine-dependent information, e.g., addresses in stacktrace. Such signatures are comparable, which enables us to determine how similar two reports are by comparing their signatures. One naive approach is to calculate the Levenshtein distance between two signatures. The smaller the distance is, the more related these two reports are.

We attach the signature to each crash report. When a crash happens, before we display all related reports to the user, we can first prioritize them and show the user most relevant ones. One of the the project goals is to integrate Apport with Debian bug reporting system (BST). To prevent crash report flooding we can leverage the crash signature to ensure that bugs/crashes that have been reported will not be reported again.

==== 1.2 Offline Support ====

For Debian boxes that are completely isolated from network, we could use similar strategies to apt-offline. However, our goal is different from that of apt-offline.

apt-offline aims to copy data (the archive containing packages) to a machine that has no Internet access, while apport wants to send data (crash reports) out. We could let the user save bug reports to a removable medium. Once the removable media is connected to a box that has can access the Internet, reports will be uploaded.

For boxes behind a firewall, but in the same network there exist other machines that can access the Internet, we could let the user configure an “apport proxy”, through which crash related reports could be pulled in and new reports could be sent out. Potential security issues need to be considered because such proxy might be abused.

==== 1.3 GUI Improvements ====

If desktop environment is available, Debian Apport interacts with users through a graphical user interface (GUI) to handle newly generated bug report. However, at this stage the GUI’s functionality is very limited.

1. The GUI can only show one report at a time. It is impossible for users to examine potentially related reports that have been recorded in Debian BST.

2. It does not allow users to export reports.

3. It just tells users that bugs cannot be reported due to the lack of debug symbols, but does not try to help users install them.

To address these limitations and improve Apport GUI’s usability, we should add more features.

1. Displaying related bug reports (adding a “Fetch Existing Reports” button). Apport pulls in all related bug reports, then displays them to the user. As mentioned before,Apport prioritizes downloaded reports and shows most similar ones first. This feature will better assist the user in addressing the bug, and ensure that the candidate bug report has not been report yet.

2. Exporting reports (adding a “Export Report” button). This allows the user to save bug reports in text form, which is extremely useful for Debian boxes that do not have Internet access.

3. Once Apport finds debug symbols are not available, it prompts up a dialog to ask the user’s permission for downloading and installing debug symbols automatically.

=== 2. Plan ===

According to the project description and my ideas, I have made a doable plan, which is shown in the figure below. This plan might be quite conservative. It is likely that we need less time than what I listed, and some works can go simultaneously. In addition, besides these goals, we may find more interesting ideas while we are working on it.


Apport for Debian

Description of the project: Apport intercepts Program crashes, collects debugging information about the crash and the operating system environment, and sends it to bug trackers in a standardized form. It also offers the user to report a bug about a package, with again collecting as much information about it as possible.

In Debian, we'd like to see Apport play flexible roles. Apport could serve as a crash detection tool, and also upon opt-in, as a Bug/Crash reporting tool. I'd also like to see functionality to save bug reports. This would allow users to save the state and then work on it later, at their leisure.

Offline Functionality: Apport has impressive retracing mechanism, where in it can download all the debug symbols for a package, to generate a proper stack trace. What to do when the crash is triggered on a box with no network? Share some ideas from apt-offline on how to download dependent packages on a different box.

  • Confirmed Mentor: Ritesh Raj Sarraf

  • How to contact the mentor: rrs@debian.org, IRC: rrs|?RickXy

  • Confirmed co-mentors: Aron Xu

  • Deliverables of the project:

    • Notification tool - Provide a generic notification tool, that can detect apport crash reports, and notify the user. Today, we are doing it with a small daemon.

    • Integration with Reportbug - Integrate Apport with reportbug to stand as a secondary bug reporting tool. Use as much of reportbug's modules, as possible.

    • Integration with Debian BTS - Integrate Apport with Debian's BTS. As of today, apport has a crashdb for Debian. It can take a bug/crash report and craft an email based bug report that is understood by Debian BTS. Add more improvements to it, like:

      • Draft all emails with a custom tag assigned only for Apport (Usertags?)
      • Make apport crash reporting reliable - By reliable, we mean Do our best to ensure that the candidate bug report is really a genuine problem, and has not yet been reported.

    • Display bug reports - If connected to the internet, pull in all bug reports (with the particular usertag?) and display it to the user, for possible duplicate

    • Scan bug reports - If we pull in the bug reports, try to do a crash signature scan, to guess possible duplicate.

    • Offline functionality - What about Debian boxes that do not have network, or are behind a firewall???

  • Desirable skills: Shell, Python, C, Debugging.

  • What the student will learn: Student will gain deeper knowledge of when and why programs crash (Actual bugs vs Integration Issues, Library Transitions), How to reliably detect and Debug them.

  • Related projects: apport