Crashing bugs can be the most annoying ones, leading to data loss, downtime and frustrated users. It would be good if applications crashed less.

Because of the complexity of the machine context, crashes often can't be reproduced in reasonable time for an ordinary user. That doesn't mean that the bug is rare - It could simply mean that the thing that triggers it occurs rarely for each user (for example DST changes). Such bugs are unlikely to be fixed unless a lot of users report them. It would be good if more crashes were reported.

To debug crashes, the developers need as much unambiguous context as possible. Generated crash reports are good, because they're usually detailed and accurate. Users can't be expected to zealously observe and report all the context manually, so they often submit sparse and wrong information.

The target audience for a lot of applications is not developers or sysadmins, but rather the general public, at home or at work. Such users can't be expected to know how to collect crash information manually, or to install -dbg packages, but generated reports from such users can still be usable. Some applications have their own crash reporting tools, but in my experience these rarely work, and when they report that they failed to report the error there doesn't seem to be any information on how to do it manually (I've observed this for recent versions of both Firefox and Flash). System-wide generation of crash reports would be good.

Is there any sort of crash report generation* which can be enabled globally** without installing a ton of -dbg packages, reading the documentation of each and every application, or slowing a normal machine down to a crawl?

* Logs, core dumps, stack traces, whatever

** Not necessarily for init, but at least for a significant subset of the applications running on a typical desktop Linux installation. In my experience GUI applications crash 100+ times more frequently than shell applications, so GUI applications would naturally be the focus.

  • What would you do with all those core files (yes, you can enable core dumps globally, but apps could individually disable them)? How do you educate users about what to do with them, how to clean them up?
    – Mat
    Feb 8, 2012 at 14:28
  • 1
    Send them to the developers. At least most of them should be familiar with email attachments.
    – l0b0
    Feb 8, 2012 at 14:33
  • 1
    What about security issues? core dumps can be full of personal information. I'm sorry, but I don't seen anything generally practical in what you propose.
    – Mat
    Feb 8, 2012 at 14:36
  • Crash reports and stack traces, on the other hand, should not contain any personal information. Even those should be enough to debug a lot of applications, if they were only generated by default and easy to find.
    – l0b0
    Feb 8, 2012 at 16:41
  • 1
    Stack traces aren't all that useful without debugging information (or at least exact binary versions that go with them). "Crash report" is an application-level concept, not something you could "enable globally" (although some frameworks provide them, and the large ones (KDE for instance) already have automatic "send to dev team" features).
    – Mat
    Feb 8, 2012 at 16:44

2 Answers 2


Put this:

ulimit -c unlimited

into file


This may not work on all distros.

Also read this articles:




Ubuntu has Apport just for that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .