This is even possible with programs implemented to only ever have a single process running at a time, under limited circumstances, such as if the crash happens as the program is exiting (thus substituting abnormal for normal termination, which may not affect user experience in any obvious way).
Therefore, I recommend you actually go ahead and report the crashes Apport has told you about, before reporting what you suspect may be a bug in Apport itself. (Or after, if you've already filed the report for Apport.) The information submitted in your bug reports for the LibreOffice and Chromium crashes is very likely to shed light on whether or not said crashes were real, and thus also on whether or not it is a bug for Apport to think they were.
Configure Apport to report to Launchpad instead of via Whoopsie. (As described in my answer there, add
'Crash' to the
probem_types list in
When Apport detects a crash it creates a
.crash file in
/var/crash. You can run
ubuntu-bug with the path to the crash file as an argument.
For example, in one of my systems'
/var/crash folders, I have
grub2-themes-ubuntu-mate.0.crash. If I were to run
cd /var/crash followed by
ubuntu-bug grub2-themes-ubuntu-mate.0.crash, Apport would start the bug reporting process for that crash by submitting data it had gathered and stored in that
.crash file, then open a web browser window where I could fill out a bug report.
So you should do this for your LibreOffice and Chromium crashes (one at a time).
Sometimes a crash is sufficiently common and recognizable that Apport sends you to the existing bug report for it instead of giving you the opportunity to write your own. If that happens, and you have information to add to the bug report, you can post a comment on it.
If you believe you may be suffering from the bug (you can judge this based on the information in the report, but in this situation you very probably are), then you should use the green "This bug affects..." link near the top of the bug report to indicate you are also affected. Optionally, you may also wish to subscribe to the bug to receive email about its progress.
But for bugs that haven't already been reported with sufficient technical detail and then re-reported multiple times, you will be given the opportunity to report a bug yourself.
In the web browser, describe fully what was happened leading up to Apport informing you that your applications that seemed to be properly functioning had crashed. Since you suspect there may not have been a real crash and that Apport may be mistaken, you should mention that too (and explain why--i.e., that the applications seemed to be working fine and they continued running). But make sure you provide sufficient factual detail for triagers and developers to allow them to (a) comprehend the report and (b) develop their own hypotheses relying solely or primarily on reported facts. Their initial thoughts may be the same as or different from yours (and may be right or wrong).
You should also include links to other relevant bug reports, which in this case will be yours. Assuming you go ahead and report both the Chromium and LibreOffice crashes, you'll have two bug reports. The second report you fill out can include a link to the first bug. Then you can edit the first bug report to include a link to the second.
If you've already filed a bug against Apport, you should include a link to it in your LibreOffice and Chromium reports (and explain its significance, of course).
When you report a crash bug, it will usually be automatically set as private. This is because it's possible for sensitive personal information processed or otherwise accessed by a crashed program to be contained in the core dump that Apport usually includes when you file a crash bug--and to a secondary extent, sensitive information could be contained in registers (their state is usually included) or passed as argument to functions listed in the automatically included stack trace.
It's okay for your bug reports to remain private. Likely, provided the core dump can be removed and the report can be inspected by a triager, they'll become publicly accessible. Whether or not that happens, work on them can progress.
If you are confident no sensitive information was conveyed, you have the option to mark them public yourself. But you should not feel pressured to do this. It can be helpful under some circumstances but it is by no means necessary, for your bug reports to be effective.
Links to a private bug report don't allow someone who doesn't have access to it to gain access. Therefore, you can feel secure in including links to a private bug report in other bug related bug reports (private or not).
Even a cursory inspection of the Chromium and LibreOffice bug reports may be sufficient for people to determine to high degree of certainty if the crashes they document are real. Or it may take time. Usually, the stack traces included in Apport bug reports are initially less than ideal, due to the absence of some debug symbols packages on your system. A bot on Launchpad runs a retrace, filling in missing debug symbols and often illuminating the conditions and nature of the crash.
If there are interested individuals who you wish to allow to see your bug even if it's private, you can subscribe them to the bug, on the bug page. Feel free to subscribe me to any bugs you file in connection with the topic of this question. (If you do, I recommend you also post a comment or something, to make sure I know you've done so and that you want me to look at something.) But before you do, take note:
- I am not an expert in fixing bugs. It is possible I will not be able to help. And I cannot commit to providing continued assistance, though I'll probably try to help out. I suspect I'd have further insight into whether or not a crash bug represents a real crash by looking at the files Apport has attached to it, but I cannot promise even that.
- It is not necessary for you to subscribe me or anyone else to a bug report. The necessary groups will already be subscribe and the necessary individuals will see the report.
- You might prefer simply to show me (or whoever) the stack trace or retrace from the bug, to minimize access to potentially sensitive information, if the bug is still private.
- You might feel comfortable looking through a stack trace yourself and satisfying yourself that none of the variables in it contain sensitive information like passwords or credit card numbers. Then, if you feel comfortable doing so, you could post it publicly on http://paste.ubuntu.com (or elsewhere), opening it up to the whole community's consideration, without having to give everyone access to potentially more sensitive data in the bug report such as the core dump file.
After submitting your bug reports and expressing both the available facts (by description and through the file automatically attached by Apport) and your concerns that the crashes may have been identified and reported erroneously, it is likely sufficient simply to wait.
Your bug may be automatically (by a bot) or manually (by a triager or developer or, occasionally, a member of the community who is neither) be made a duplicate of an existing bug report, commented on, closed, confirmed, triaged and assigned a severity, or some combination of those things. Any of these actions would likely shed light on the nature of what was reported, including whether or not it was a real crash.