Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: $ coredumpctl | grep gnome-shell Fri 2017-09-08 21:51:20 +05 19301 1000 1000 11 missing /usr/bin/gnome-shell Fri 2017-09-08 21:51:32 +05 1075 42 42 11 missing /usr/bin/gnome-shell Sat 2017-09-09 10:21:28 +05 22361 1000 1000 11 missing /usr/bin/gnome-shell Sat 2017-09-09 13:40:59 +05 13422 1000 1000 11 missing /usr/bin/gnome-shell Sat 2017-09-09 23:53:11 +05 2867 1000 1000 11 missing /usr/bin/gnome-shell Sat 2017-09-09 23:54:08 +05 13938 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-10 02:43:36 +05 1627 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-10 06:10:31 +05 10431 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-10 12:43:35 +05 2717 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-10 12:57:09 +05 1734 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-10 12:57:49 +05 5182 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-10 12:58:26 +05 6782 1000 1000 11 missing /usr/bin/gnome-shell Fri 2017-09-15 23:15:13 +05 1889 1000 1000 11 missing /usr/bin/gnome-shell Sun 2017-09-17 11:44:07 +05 1815 1000 1000 5 missing /usr/bin/gnome-shell Sun 2017-09-17 12:47:14 +05 26398 1000 1000 5 missing /usr/bin/gnome-shell Sun 2017-09-17 13:29:21 +05 26810 1000 1000 5 missing /usr/bin/gnome-shell Sun 2017-09-17 13:35:57 +05 16719 1000 1000 5 missing /usr/bin/gnome-shell Sun 2017-09-17 14:08:12 +05 1214 1000 1000 5 truncated /usr/bin/gnome-shell [mikhail@localhost ~]$ coredumpctl gdb 1214 PID: 1214 (gnome-shell) UID: 1000 (mikhail) GID: 1000 (mikhail) Signal: 5 (TRAP) Timestamp: Sun 2017-09-17 14:07:59 +05 (2min 57s ago) Command Line: /usr/bin/gnome-shell Executable: /usr/bin/gnome-shell Control Group: /user.slice/user-1000.slice/session-18.scope Unit: session-18.scope Slice: user-1000.slice Session: 18 Owner UID: 1000 (mikhail) Boot ID: bfea69129f1d43fcb8f0fe720c948e48 Machine ID: 75b6ee13430d4cc7923b3637b296deec Hostname: localhost.localdomain Storage: /var/lib/systemd/coredump/core.gnome-shell.1000.bfea69129f1d43fcb8f0fe720c948e48.1214.1505639279000000.lz4 (truncated) Message: Process 1214 (gnome-shell) of user 1000 dumped core. Stack trace of thread 1214: #0 0x00007f10195167b1 n/a (n/a) GNU gdb (GDB) Fedora 8.0-25.fc28 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/gnome-shell...Reading symbols from /usr/lib/debug/usr/bin/gnome-shell-3.26.0-1.fc28.x86_64.debug...done. done. BFD: Warning: /var/tmp/coredump-TiktnF is truncated: expected core file size >= 2955698176, found: 2147483648. [New LWP 1214] [New LWP 1216] [New LWP 1234] [New LWP 1235] [New LWP 1238] [New LWP 1239] [New LWP 1236] [New LWP 1241] [New LWP 1240] [New LWP 1243] [New LWP 1242] [New LWP 1245] [New LWP 1218] [New LWP 1244] [New LWP 1215] [New LWP 1237] [New LWP 1233] Cannot access memory at address 0x7f101a43b108 Cannot access memory at address 0x7f101a43b100 Failed to read a valid object file image from memory. Core was generated by `/usr/bin/gnome-shell'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x00007f10195167b1 in ?? () [Current thread is 1 (LWP 1214)] (gdb) bt #0 0x00007f10195167b1 in ?? () Backtrace stopped: Cannot access memory at address 0x7fff4a5d73e0 (gdb) But when I connected manually to crashed process backtrace got correctly. For example: https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&trace_id=237973
Yes, that's not a bug. As you can see in the listing, core file is listed as "truncated". There's a ExternalSizeMax=2G default setting in /etc/coredump.conf. We do this to avoid storing and processing core files that are too big (some machines have terabytes of ram...). A truncated core file is still potentially useful, depending on the memory layout, so we keep it. If you want to catch such cores, I suggest increasing ProcessSizeMax= and ExternalSizeMax=. I'll close this, because things are working as intended here, even though this isn't particularly convenient in your case.
Can you also support value 0 for ExternalSizeMax=0 and ProcessSizeMax=0 for unlimit store?
0 to mean unlimited is unlikely, at least I would be against. Something like "unlimited" or "max" would be possible. If you think that'd be useful, please open a bug upstream at https://github.com/systemd/systemd/issues/new, so this can be discussed.
What differences between /etc/coredump.conf and /etc/systemd/coredump.conf? /etc/systemd/coredump.conf already contain ExternalSizeMax and ProcessSizeMax parameters, but this lines are commented. Which config file actually works? I am try googling about this but only finded /etc/systemd/coredump.conf description. > Something like "unlimited" or "max" would be possible. Thanks if it really works, because I don't want to care about size of this parameters, I only want that this always works as expected.
My bad, it's /etc/systemd/coredump.conf.