Apport doesn't overwrite existing core files

(I'm running Gutsy, BTW)

That coretst file is not part of Ubuntu, is it? Maybe something is wrong in that file.

"coretst" is a program I wrote which simply dumps cores. I wrote it to show that the core dump behavior of Ubuntu doesn't match the documentation. That is, that pre-existing core dumps aren't being overwritten when they should. And Ubuntu's core dump behavior is _definitely_ part of Ubuntu...

As it turns out, this is a bug in apport. The attached patch makes apport conform to the behavior described in core(5).

Upon further investigation, it looks like the Linux kernel opens the core file with "O_CREAT | O_NOFOLLOW | O_LARGEFILE", then performs the checks listed core(5): http://lxr.linux.no/linux+v2.6.26.3/fs/exec.c#L1749

Apport appears to change its uid/gid to the failing process, then tries to open the core file with "O_WRONLY | O_CREAT | O_EXCL". This takes care of the permission check specified in core(5), but it doesn't handle any of the others. In particular, using O_EXCL, means it doesn't overwrite pre-existing core files, which is the source of my original complaint.

core(5) says core files should be created except in the following cases:

       * The process does not have permission to write the core file.
              (By default the core file is called core, and is created in the
              current working directory. See below for details on naming.)
              Writing the core file will fail if the directory in which it is
              to be created is non-writable, or if a file with the same name
              exists and is not writable or is not a regular file (e.g., it is
              a directory or a symbolic link).

       * A (writable, regular) file with the same name as would be used
              for the core dump already exists, but there is more than one
              hard link to that file.

       * The file system where the core dump file would be created is
              full; or has run out of inodes; or is mounted read only; or the
              user has reached their quota for the file system.

       * The directory in which the core dump file is to be created does
              not exist.

       * RLIMIT_CORE or RLIMIT_FSIZE resource limits for a process are
              set to zero (see getrlimit(2)).

       * The binary being executed by the process does not have read per‐
              mission enabled.

       * The process is executing a set-user-ID (set-group-ID) program
              that is owned by a user (group) other than the real user (group)
              ID of the process. (However, see the description of the
              prctl(2) PR_SET_DUMPABLE operation, and the description of the
              /proc/sys/fs/suid_dumpable file in proc(5).)

My patch doesn't address any of these, and should be ignored.

Ether Apport should be updated to conform to these cases, or the core(5) man page should be updated to note Apport's behavior.

Also, if ApplicationA crashes and Apport fails to overwrite an old core file from ApplicationB which happens to be lying around, wouldn't the report generated by Apport be at best useless, and at worst misleading?

Please note that apport doesn't actually use the written core files; they are just a convenience for developers. So crash reports filed through apport will always match the correct package/program.

This problem still exists in Karmic. Please se LP: #487759 for another example testcase.
The current behaviour makes it quite difficult to do local debugging with gdb when apport is active, so I hope there can be a fix.

Kind regards,

Alain

Sorry for double-posting. In LP: #487759, have a look at the attached ApportLog.txt . In two separate runs I killed the same binary using two different signals. Only the first coredump was written.
The reason I find this important is that I want to help with investigating why Samba's nmbd dies when the network is not yet configured (LP: #462169, a High priority bug), and would like to use apport's marvelous backtrace functions as a showcase for its great potential :)

Can confirm is still in 12.04.

Perhaps I misunderstand the scope of this bug, but AFAICT this makes every core file submitted by every user to help developers debugging every issue in Ubuntu potentially a red herring, because when a user submits a core it will be from the first crash that occurred rather than the most recent one. Is the main way that people debug their software on Linux being broken really of 'Low' importance? How the heck has every developer put up with this for the last 4 years? :P

In particular this is nasty for development because it means after you fix a bug in your source and rebuild, if your program still crashes but for a different reason than before it will appear as if you didn't fix the bug because the core will be the same. Thankfully gdb warns when the executable is newer than the core or I wouldn't have caught this...

What, 5 years with no fix? I finally got annoyed enough at this and started looking into why Ubuntu is doing this and how to change it. I assumed it was intentional, but now I see it's a bug. Highly annoying for developing software under Ubuntu.

Here's how to disable apport and get the core handling necessary for development:

http://askubuntu.com/questions/93457/how-do-i-enable-or-disable-apport

9 years later and still broken! Can confirm still exists in 16.04. Does no one develop on Ubuntu or has every developer in the last nine years manually removed apport?

@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.

Same problem here!

And nearly 13 years later, we are still here.

If I have a core file in the Current directory and another run of the program encounters a fault, the old core (possibly months old) prevents the current core file from being written. Outstanding!