Comment 14 for bug 160999

@k04jg02, as noted in comment #7, this bug has no effect on the Ubuntu Error Reporting process for software that is distributed through normal channels.

Instead, for software that comes from any other source, apport seems to make a 'best-efforts' approach to dump a core file, roughly following some of the conventions of the usual core dump procedure. However, there's nothing in core(5) that says that any downstream program receiving a core dump (in this case apport) must do anything specific with it.

That said, for developers, and in particular newbies trying to get into coding, apport's behavior is fairly insidious and confusing. Here are a few suggestions and possible workarounds for consideration:

-[partial workaround] If you set the `kernel.core_uses_pid` sysctl to 1, apport respects this and always generates core.PID files. This doesn't solve the broken default behavior, and also doesn't guarantee a new file, since PIDs can be reused, but it helps. (`sysclt kernel.core_uses_pid=1`, or edit /etc/sysctl.conf)

-[questionable workaround] Use apport to capture crashes for unpackaged software, by adding the lines
```[main]
unpackaged=true```
to ~/.config/apport/settings. Now your program crashes will be handled like those of any Ubuntu-provided software: They will generate a .crash file in /var/crash (which can be unpacked with apport-unpack to access the core dump); they will generate an apport crash dialog box, and will even be uploaded to errors.ubuntu.com by whoopsie if you check the 'Send error report' box, (which is almost certainly a bad idea).

-[upstream solution] kernel could support both writing out a core file (according the rules in core(5) , and passing the core to an external program. This would be ideal, since it would not require apport to try to duplicate and track kernel core dump behavior.

-[mitigation] Patch apport to just make the default behavior a little more sane, even if not perfectly copying the usual behavior.