Version-Release number of selected component: caja-1.8.2-1.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: caja crash_function: rate_limiter_free executable: /usr/bin/caja kernel: 3.17.3-200.fc20.i686 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (6 frames) #0 rate_limiter_free at gfilemonitor.c:160 #1 g_hash_table_remove_node at ghash.c:448 #2 g_hash_table_foreach_remove_or_steal at ghash.c:1412 #3 g_hash_table_foreach_remove at ghash.c:1456 #4 rate_limiter_timeout at gfilemonitor.c:573 #10 gtk_main at gtkmain.c:1257
Created attachment 962799 [details] File: backtrace
Created attachment 962800 [details] File: cgroup
Created attachment 962801 [details] File: core_backtrace
Created attachment 962802 [details] File: dso_list
Created attachment 962803 [details] File: environ
Created attachment 962804 [details] File: exploitable
Created attachment 962805 [details] File: limits
Created attachment 962806 [details] File: maps
Created attachment 962807 [details] File: open_fds
Created attachment 962808 [details] File: proc_pid_status
Created attachment 962809 [details] File: var_log_messages
*** Bug 1187705 has been marked as a duplicate of this bug. ***
Can you describe a little more detailed what happend? Did this issue occurs frequently ? ... my crystal ball is dead......
I'm sorry, I don't have any other more information than the automatically created bug report https://bugzilla.redhat.com/show_bug.cgi?id=1187705 . I organize my desktop with the panel on the right and a 4x4 grid of workspaces. I am a developer, and I want as much vertical space as possible. Mate is one of the few desktops that lets me move the panel to the right and lets me switch between workspaces easily, and I would like to thank everyone who worked on it. In any case, I sometimes get the error about caja crashing when I am in a workspace with chrome running. It happens maybe once or twice a month. I do not know how to recreate it. I do not do anything fancy on the desktop. My workspaces are running either chrome, thunderbird, xterm, or one of my X11 programs. I almost never open caja. My guess is that chrome or some other program touched (or maybe created and then removed) something in a directory that caja is watching and somehow confused caja. The stack trace mentions gfilemonitor.c, which sounds like something that watches files. Regards, William
Another user experienced a similar problem: I was typing in an xterm window. I do not know what caused the problem. reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: caja crash_function: rate_limiter_free executable: /usr/bin/caja kernel: 3.17.8-200.fc20.x86_64 package: caja-1.8.2-1.fc20 reason: caja killed by SIGSEGV runlevel: N 5 type: CCpp uid: 214
Another user experienced a similar problem: It happened while I was typing in an xterm. chrome and thunderbird were open on other workspaces. reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: caja crash_function: rate_limiter_free executable: /usr/bin/caja kernel: 3.17.8-200.fc20.x86_64 package: caja-1.8.2-1.fc20 reason: caja killed by SIGSEGV runlevel: N 5 type: CCpp uid: 214
OK, it happens very often. I never use xterm, can you give mate-terminal a chance for testing? To summarize, all this crashes happends when no caja window is open and caja is running in the background to handle the desktop? I'm not using thunderbird (me claws-mail), maybe caja crashs for an incomming mail in thunderbird. Only mail progamms are writing in home regularly during runtime . I can't imagine that crome (me firefox) cause the issue, because a browser writes only in home if settings are changed but not regularly. But i will use chrome for testing now, maybe i can reproduce something.
It usually does not happen three times in 24 hours. Maybe it is upset by the bug reports. I think that I need xterm because I use my own version of microemacs http://williambader.com/pat/emacs.tar.bz2 gnome-terminal (on gnome2 on older versions of Fedora) didn't work right, although I just tested and it seems to work OK on mate-terminal now. I launch xterm with xterm -geometry 177x52+0+0 -font 10x20 +sb +sm -ls -fg white -bg black -xrm '*VT100*colorBD: cyan' -xrm '*VT100*colorUL: yellow' gnome-terminal does not let me select the 10x20 font. I send email with thunderbird, but I pull email with fetchmail and read it with gnu-emacs rmail. I wrote my own mail-check and screen-brightness panel applets. They both write to log files in $HOME when they start, but they do not write files when they are idle.
gfilemonitor is a glib/gio function. From https://developer.gnome.org/gio/stable/GFileMonitor.html Monitors a file or directory for changes. To obtain a GFileMonitor for a file or directory, use g_file_monitor(), g_file_monitor_file(), or g_file_monitor_directory(). I searched for 'rate_limiter_free at gfilemonitor.c:160' too, and surprise....surprise, i found that hit. https://bugzilla.redhat.com/show_bug.cgi?id=1176119 and there are more hits with other applications. I'm thinking more and more that this is a issue with gio itself.
Can you provide a current backtrace from your abrt directory? /var/tmp/abrt/<bug>/ If there isn't one create it with 'abrt-action-analyze-ccpp-local' inside the directory.
Created attachment 987329 [details] backtrace file caja crashed again at the moment that I pasted text into a field in a web page open in chrome. Now that I think about it, the other crashes happened while I was typing or moving the mouse. Is the current source at https://git.gnome.org/browse/glib/tree/gio/gfilemonitor.c ? Since stack trace shows a crash at rate_limiter_free (limiter=0x0) at gfilemonitor.c:160 would it be worth hacking rate_limiter_free() not to do anything if limiter is NULL? The next higher up is g_main_context_poll() in https://git.gnome.org/browse/glib/tree/glib/gmain.c It has a lot of debug code, which is sometimes a bad sign. It does a poll on a set of file descriptors, which might be related to crashes during input events.
I had a talk with mate devs today. and we pretty shure that it isa glib2 issue. Comment from mate dev at https://bugs.launchpad.net/fedora/+bug/1398828 ``` This looks more like a glib2.0 bug. The whole stacktrace is made of the functions from gio or glib. First g_hash_table_foreach_remove_or_steal function calls g_hash_table_remove_node [1], then it gets to rate_limiter_free function, whose argument ("limiter") equals 0 at that moment for some reason. Right after that it crashes on dereferencing NULL pointer [2]. I can't explain why all that happens, it's all internal glib/gio stuff, but I'm pretty sure something should be corrected in that code. The similar report from Fedora 20 where glib2.0 is 2.38 and it's another application (caja) that crashes also confirms that the problem is in glib2.0. [1] https://git.gnome.org/browse/glib/tree/glib/ghash.c?h=glib-2-40#n1436 [2] https://git.gnome.org/browse/glib/tree/gio/gfilemonitor.c?h=glib-2-40#n165 ``` see also https://bugzilla.redhat.com/show_bug.cgi?id=1149412 and upstream report https://bugzilla.gnome.org/show_bug.cgi?id=720489 I will re-asign it to glib2
Thanks for looking into the problem. The bug reports that you referenced suspect a race between threads. I think that could explain how the pointer became NULL. My laptop has 2 cores with 2 threads per core (i5-2450M CPU @ 2.50GHz), 8GB RAM, /tmp on tmpfs, and a Samsung SSD 840 PRO. $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 245486784 145320920 87672808 63% / devtmpfs 4031560 0 4031560 0% /dev tmpfs 4042188 17812 4024376 1% /dev/shm tmpfs 4042188 968 4041220 1% /run tmpfs 4042188 0 4042188 0% /sys/fs/cgroup tmpfs 4042188 8 4042180 1% /tmp /dev/sda1 499656 139972 322988 31% /boot Since only a few people have reported the problem, is there something special about my configuration that makes races more likely?
I have a similar CPU in my notebook MSI FX700 (intel i5-M460) with 2 cores and 2 threads per core, and i use same ext4 partition schema as you ( / + /boot ) with a SSD. I never saw that issue there, but i use my laptop only for travelling (not every day usage). For me you're using a normal configuration.
*** Bug 1170280 has been marked as a duplicate of this bug. ***
*** Bug 1192056 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.