I think there is too much speculation happening in this bug report. :)
- /etc/default/apport's maxsize value isn't used anywhere since commit 1195
(and should be removed from this config file -- this is a separate issue, bug
719564).
- /etc/security/limits.conf is only used by PAM. X running as root from
/etc/init (gdm) will not end up with these rlimits applied (and, regardless,
coredump limits are ignored for the /proc/sys/kernel/core_pattern handler
except when _not_ catching the crash (i.e. coredump writing pass-through)).
The error message given here relates strictly to size of the coredump vs
available physical memory. If the coredump is larger than 3/4 of
available memory, it will not attach it to the crash report, so this
error message is accurate.
So, the question remains: how large is the X coredump, and how much free
memory do you have?
As an example, on my system, I could catch an X crash. I have about 5GB
of memory available, and X's memory footprint is about 128MB:
$ echo $(cat /proc/meminfo | egrep '^(MemFree|Cached|Writeback):' | awk '{print
$2}') - + p | dc
4993428
$ grep ^VmSize /proc/$(pidof X)/status
VmSize: 128796 kB
** Changed in: apport (Ubuntu)
Status: Confirmed => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/718635
Title:
Error message "Your computer does not have enough free memory" when
core dump or stacktrace failed to be created is misleading
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
