touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #12720
[Bug 1346497] Re: apport computes incorrect core dump size limit
This bug was fixed in the package apport - 2.14.7-0ubuntu1
---------------
apport (2.14.7-0ubuntu1) utopic; urgency=medium
* New upstream release:
- Fix interpretation of core dump ulimits: they are in bytes, not KiB.
(LP: #1346497)
- apport-retrace: Don't require specifying an operation; default to
updating the given .crash file. (LP: #1361242)
- Write report even on UnreportableReasons, so that whoopsie can still
upload them. (LP: #1360417)
- apt/dpkg install_packages(): Write a "packages.txt" into sandbox root
directory to keep track of installed packages and their versions.
Prerequisite for LP #1352591.
- apt/dpkg install_packages(): Avoid re-downloading/installing packages
which are already installed into a permanent sandbox. Prerequisite for
LP #1352591.
- sandboxutils.py, make_sandbox(): Drop check for already existing files
when dynamically resolving libraries and ExecutablePaths; with that,
these packages would never get updated in a permanent sandbox. The new
version tracking from above now takes care of that. (LP: #1352591)
- Fix report.test_add_proc_info test to stop assuming that pid 1 is named
"init", as one can specify a different one on the kernel command line.
- report.py, add_gdb_info(): Check for truncated core dumps, and set
UnreportableReason and raise an IOError on them. Handle this in
apport-retrace and whoopsie-upload-all to fail properly instead of
silently producing broken Stacktraces. (LP: #1354571)
-- Martin Pitt <martin.pitt@xxxxxxxxxx> Fri, 29 Aug 2014 12:38:54 +0200
** Changed in: apport (Ubuntu)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1346497
Title:
apport computes incorrect core dump size limit
Status in “apport” package in Ubuntu:
Fix Released
Bug description:
On Ubuntu 14.04, calling the shell's "ulimit -c 20" command sets a ULIMIT_CORE in the kernel of 20480 bytes, as expected, verified by looking at /proc/$$/limits. (This is just an example; I'd likely not use a value that low.) The contents of /proc/sys/kernel/core_pattern is
|/usr/share/apport/apport %p %s %c %P
When a process gets a memory fault, a core file much larger than 20480
bytes can be created; apport multiplies its third argument, 20480, by
1024, giving a limit of 20MB.
Test program:
#include <sys/time.h>
#include <sys/resource.h>
#include <stdlib.h>
#include <stdio.h>
main()
{
struct rlimit r;
getrlimit(RLIMIT_CORE, &r);
printf("%ld %ld\n", (long) r.rlim_cur, (long)r.rlim_max);
malloc(1000000);
abort();
}
This produces a core dump of around 1.2MB.
Excerpts from /var/log/apport.log for the test program :
ERROR: apport (pid 4574) Sun Jul 20 21:37:38 2014: called for pid 4573, signal 6, core limit 204800
ERROR: apport (pid 4574) Sun Jul 20 21:37:38 2014: executable: /home/mp/ab (command line "./ab")
ERROR: apport (pid 4574) Sun Jul 20 21:37:38 2014: executable does not belong to a package, ignoring
ERROR: apport (pid 4574) Sun Jul 20 21:37:38 2014: writing core dump to /home/mp/core (limit: 209715200)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1346497/+subscriptions