Red Hat Bugzilla – Bug 471966
Nautilus fails to start on the XO
Last modified: 2015-03-03 17:33:30 EST
Description of problem:
When booting the XO, and logging in as the liveuser, nautilus often fails to start. A message appears indicating that I must kill bonobo-activation-server. Following that step, allows nautilus to start again. However, after logout/login it continues to fail to start.
Version-Release number of selected component (if applicable):
80% <--- sometimes it doesn't fail to start. I'm unable to determine the root cause of this irregularity.
Steps to Reproduce:
1. Boot the XO
2. Login as liveuser (automatically or manually)
* The following message appears on login:
Nautilus cannot be used now, due to an unexpected error
Nautilus cannot be used now, due to an unexpected error from Bonobo when attempting to locate the factory. Killing bonobo-activation-server and restarting Nautilus may help fix the problem
* nautilus should start without error
* $HOME/.xsession-errors contains (full log available from http://jlaska.fedorapeople.org/xsession-errors):
** (gnome-panel:2917): WARNING **: panel-applet-frame.c:1285: failed to load applet OAFIID:TomboyApplet:
The program 'nautilus' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
(Details: serial 480 error_code 163 request_code 148 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
** (nautilus:3044): WARNING **: Unable to add monitor: Not supported
** Message: <info> No keyring secrets found for Auto rh-wireless/802-11-wireless-security; asking user.
This is probably fallout from my background fading patch.
Ray -- I'm not actually sure about that.
I didn't see this at first on my XO, but after about 5 quick login/logout cycles, I got it. I've tried in a KVM guest over a dozen times of login/logout without successfully getting it to occur.
I wonder if what we're actually seeing is a race condition. Looking at the code (nautilus/src/nautilus-application.c:650 or so), we're getting back that the registration was successful but we're then not able to find ourselves. I don't remember if b-a-s registration is synchronous, but my fuzzy memory says it's not. Which means we could get run here before b-a-s finishes registering us enough to work. It even looks like there's a loop set up for retrying, but we never actually go through it more than once
Well, the .xsession-errors log shows nautilus dying from a "BadRenderPicture" error, so it's dying because of some cairo related drawing call.
I think Nautilus has a separate bug where if it dies under some circumstances it doesn't come back without killing bonobo-activation-server. It could be the BadRenderPicture is making it die initially, and then the session manager is restarting it causing the activation-server woes.
Hmmm, could be. The fact that nautilus was still running led me to think that we could eb there. I'll try to turn off respawn of it in the session and see what happens.
And Ray -- if you want an XO to play on, there are some at my desk. You can just put the live image on a USB stick with the --xo flag and it should boot fine (4 gig usb stick preferred, if smaller, also pass --compress)
(In reply to comment #4)
> Hmmm, could be. The fact that nautilus was still running led me to think that
> we could eb there. I'll try to turn off respawn of it in the session and see
> what happens.
Okay, NAUTILUS_DEBUG=1 in /etc/profile works to avoid a respawn. Now to try to get a backtrace
so i spent some time today spinning a stick and booting an XO but had lots of fail:
1) plymouthd seems to die at the end of boot up
2) X doesn't start giving some error about "Unable to open /dev/cpu/0/msr: 2"
I guess i'll just wait for your backtrace...
Having very little luck in getting one. Since it's just an XError, we don't leave around a core file even with ulimit -c unlimited. I'm currently starting nautilus inside of gdb inside of a terminal, but I've yet to get it to crash like that in over a dozen tries.
if you run with --g-fatal-warnings should dump a core file i think (unless there are other warnings before it)
grr, scratch that. gdk_x_error has:
g_error ("%s", msg);
#else /* !G_ENABLE_DEBUG */
g_fprintf (stderr, "%s\n", msg);
#endif /* G_ENABLE_DEBUG */
so it will only dump core if gtk is built with --enable-debug....
... and now in running it for like half an hour straight without gdb, I haven't had it fail either.
And last night it similarly took me a long time to hit it. Maybe this is less of a problem than thought unless jlaska is always seeing it. But although it has gotten reported sporadically, it seems that it comes and goes for people without much in the way of rhyme or reason :/
I'm less inclined to consider this a blocker then. I'm moving over to Target given our current timeline.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
FWIW: Just testing build 20090227 from http://dev.laptop.org/~cjb/rawhide-xo/ on an XO laptop (this is an F11 build) and I've haven't seen Nautilus failing to start (must be at least a dozen reboots by now).
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. 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 WONTFIX if it remains open with a Fedora
'version' of '10'.
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 prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 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 please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
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.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.
Thank you for reporting this bug and we are sorry it could not be fixed.