MATE .core files in home (keyring, marco, ...)

B

broozar

Hi everyone, this has been bugging me for several releases now. My Mate installation creates .core files in my home directory, even though I shut it down normally, I get no error messages and no bad behaviour. I understand that I can silence the whole mechanism by following https://forums.freebsd.org/threads/core-files.17761/, however what I would really like to know is a) why keyring, marco, and some other desktop components crash in the fist place (Have I misconfigured something? Am I shutting the machine down incorrectly?) and b) if everybody else is experiencing similar things and I should just silence it.

I should mention that it's not always the same component that produces a crash dump, and it also does not happen 100% of the time, though very frequently.

user is in wheel,video
polkit rule is set to allow shutdown from Mate https://github.com/broozar/installD...rkMate13.0/files/polkit/shutdown-reboot.rules
shutting down via console "shutdown -p/-r now" or Mate seems to make little difference
 
If you run file on the core file in question, you might get a bit more info about why it (the program) crashed.
 
I have always been bad at interpreting crash dumps. From what I can see from the core files I got this morning, gnome-keyring suffered a segmentation fault, marco a sigtrap. The lowest commonly shared process was gdbus, which I think must be enabled for Mate to run. Not sure if that is helpful.

I used lldb as suggested by the handbook. Not sure how to use file with .core, could you please explain?
 
Using file on a core file
Code: 
tingo@kg-core1$ ll *core
-rw-------  1 tingo  tingo  - 981004288 Jan 27 06:27 python3.7.core
tingo@kg-core1$ file python3.7.core
python3.7.core: ELF 64-bit LSB core file, x86-64, version 1 (FreeBSD), FreeBSD-style, from '/usr/local/bin/python3.7 /usr/local/bin/cura', pid=34115
So it tells you which process, and (in this case, since it was a Python program) which program.
 
the file names match the origin, meaning marco.core comes from marco and gnome-keyring.core comes from the respective daemon:
Code: 
$ file *.core
gnome-keyring-daemo.core: ELF 64-bit LSB core file, x86-64, version 1 (FreeBSD), FreeBSD-style, from 'gnome-keyring-daemon --start', pid=50321
marco.core:               ELF 64-bit LSB core file, x86-64, version 1 (FreeBSD), FreeBSD-style, from '/usr/local/bin/marco', pid=50797
 
As I've mentioned somewhere else on this forum debugging X application can be painful as usually they're big (it takes time to understand all the data structures that interact with each other). First start would be to check it out with debugger such as gdb by doing $ gdb `which marco`/path/to/marco/core.
In gdb you can use bt or where commands to check what happened.
 
I never get the marco core file. According to this related thread, that's probably because I have the following line in /etc/fstab:
Code: 
proc        /proc        procfs    rw    0    0

As for the gnome-keyring-daemo.core file, I don't use the gnome keyring anyway, so I crudely disable it whenever it reappears after an upgrade. To crudely disable the gnome keyring:

  1. Open "Startup Applications" in "Control Center" and untick the options titled "Certificate and Key Storage", "SSH Key Agent", and "Secret Service Agent".
  2. With root privileges, run the command chmod -x /usr/local/bin/gnome-keyring*
  3. Reboot, delete the core file, and reboot again.
After this, I won't see any core files in my home directory until, possibly, a future upgrade undoes my changes.
 
Code: 
$ grep coredump /etc/sysctl.conf
kern.coredump=0
?

Doesn't solve any problem, but at least avoids your fs to be littered with .core files. They're a debugging aid, so if you don't intend to actually debug the crash, they're useless…
 
You must log in or register to reply here.
Back
Top