Description of problem: Periodically, when running yum update, the Xorg desktop freezes (no updates). The mouse still moves, but nothing else (it would appear that certain groups of yum updates cause the issue... for example, updating libreoffice* or wine* pretty much guarantees a freeze -- I've seen it with other updates as well -- updating java or google-chrome-beta by themselves have never caused it). If I swtiched to a text console and back, I would have a black screen with a mouse pointer that moves. In the background, the yum update does complete, according to the logs (under Fedora 17, compiz would go to 100% cpu and the yum update would freeze). I thought, based on previous, that a prelink re-run was causing compiz to freak out... so, I blacklisted prelinking of compiz. This time, whilst updating libreoffice*, another freeze, and I was able to gcore compiz this time, as the binary was still there (versus deleted, so, in the past I could never gcore). As I was finishing that, caja crashed. Ok, fine. I swtiched back to the X console to check things one more time, and lo and behold my desktop is back. I did another update, this time of wine*, same freeze... caja did not crash. But, upon doing a kill of the caja pid and going back to the Xorg VT, my desktop is back. So, something in an update is causing caja to lose its lunch, and this seems to make the compiz/mate desktop no longer work. I am wondering if I should add caja to the prelink blacklist... Version-Release number of selected component: caja-1.8.2-2.fc21 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: caja crash_function: INT_cairo_set_source_surface executable: /usr/bin/caja kernel: 3.19.7-200.fc21.x86_64 runlevel: N 5 type: CCpp uid: 500 var_log_messages: [System Logs]:\n-- Logs begin at Sat 2015-02-14 23:23:44 EST, end at Fri 2015-06-05 21:43:40 EDT. -- Truncated backtrace: Thread no. 1 (7 frames) #0 INT_cairo_set_source_surface at cairo.c:758 #1 gdk_cairo_set_source_pixbuf at gdkcairo.c:284 #2 mate_bg_create_pixmap at mate-bg.c:1217 #3 eel_background_ensure_realized at eel-background.c:363 #4 eel_background_set_up_widget at eel-background.c:550 #5 background_changed_cb at eel-background.c:603 #10 gtk_main at gtkmain.c:1268 Potential duplicate: bug 1169897
Created attachment 1035527 [details] File: backtrace
Created attachment 1035528 [details] File: cgroup
Created attachment 1035529 [details] File: core_backtrace
Created attachment 1035530 [details] File: dso_list
Created attachment 1035531 [details] File: environ
Created attachment 1035532 [details] File: exploitable
Created attachment 1035533 [details] File: limits
Created attachment 1035534 [details] File: maps
Created attachment 1035535 [details] File: open_fds
Created attachment 1035536 [details] File: proc_pid_status
Why don't you erase prelink? as it causes issues for loads of software.
If prelink only breaks stuff, then why is prelink part of the system (or at least, why aren't the default blacklists set for known breakage)? and besides, it's only a guess that prelink is actually the problem (though, if prelink was introduced in Fedora 16 or 17, that lends more credence to it being the problem) -- I'll have to pay attention to if caja is "deleted" next time this happens. On the other hand, I don't see these same issues with prelink on my RHEL6 box at work (and compiz). Which would tend to lead credence to prelink *NOT* being the problem. Either way, the file manager fouling up shouldn't foul up the whole DE/Xorg.
(In reply to Dave Botsch from comment #12) > If prelink only breaks stuff, then why is prelink part of the system (or at > least, why aren't the default blacklists set for known breakage)? > > and besides, it's only a guess that prelink is actually the problem (though, > if prelink was introduced in Fedora 16 or 17, that lends more credence to it > being the problem) -- I'll have to pay attention to if caja is "deleted" > next time this happens. > > On the other hand, I don't see these same issues with prelink on my RHEL6 > box at work (and compiz). Which would tend to lead credence to prelink *NOT* > being the problem. Still wondering that caja is in rhel6? > > Either way, the file manager fouling up shouldn't foul up the whole DE/Xorg.
(In reply to Dave Botsch from comment #12) > If prelink only breaks stuff, then why is prelink part of the system (or at > least, why aren't the default blacklists set for known breakage)? > Here are two recent examples of prelink screwing stuff up https://bugzilla.rpmfusion.org/show_bug.cgi?id=3258 https://bugzilla.redhat.com/show_bug.cgi?id=1150126 > and besides, it's only a guess that prelink is actually the problem (though, > if prelink was introduced in Fedora 16 or 17, that lends more credence to it > being the problem) -- I'll have to pay attention to if caja is "deleted" > next time this happens. > I've seen it do the same to nemo and nautilus > On the other hand, I don't see these same issues with prelink on my RHEL6 > box at work (and compiz). Which would tend to lead credence to prelink *NOT* > being the problem. > > Either way, the file manager fouling up shouldn't foul up the whole DE/Xorg. It's prelink that fouls stuff, are you sure it hasn't hit some xorg lib Here's another example https://bugzilla.redhat.com/show_bug.cgi?id=1105088 [System Logs]: mai 28 19:38:39 localhost.lan yum[9949]: Updated: nemo-extensions-2.2.2-1.fc20.x86_64 mai 28 19:39:05 localhost.lan yum[9949]: Updated: nemo-2.2.2-1.fc20.x86_64 mai 28 20:24:03 localhost.lan kernel: traps: nemo[1505] general protection ip:339723305c sp:7ffff0db0730 error:0 in libgobject-2.0.so.0.3800.2[3397200000+4f000] mai 28 20:24:03 localhost.lan abrt-hook-ccpp[11109]: File '/usr/bin/nemo' seems to be deleted mai 28 20:24:05 localhost.lan abrt-hook-ccpp[11109]: Saved core dump of pid 1505 (/usr/bin/nemo) to /var/tmp/abrt/ccpp-2014-05-28-20:24:03-1505 (112848896 bytes) [User Logs]:
caja-1.8.2-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/caja-1.8.2-3.fc21
Package caja-1.8.2-3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing caja-1.8.2-3.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9687/caja-1.8.2-3.fc21 then log in and leave karma (feedback).
(In reply to Dave Botsch from comment #12) > If prelink only breaks stuff, then why is prelink part of the system (or at > least, why aren't the default blacklists set for known breakage)? It is not part of the system. That is, it hasn't been part of the default install since F19. I don't know about the other spins though (Mate etc.)
caja-1.8.2-3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.