Bug 471966 - Nautilus fails to start on the XO
Nautilus fails to start on the XO
Product: Fedora
Classification: Fedora
Component: nautilus (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F10Target FedoraOnXO
  Show dependency treegraph
Reported: 2008-11-17 16:58 EST by James Laska
Modified: 2015-03-03 17:33 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 01:52:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Laska 2008-11-17 16:58: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):

How reproducible:
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)
Actual results:

 * 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

Expected results:

 * nautilus should start without error

Additional info:

 * $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.
Comment 1 Ray Strode [halfline] 2008-11-17 17:00:12 EST
This is probably fallout from my background fading patch.
Comment 2 Jeremy Katz 2008-11-17 22:02:42 EST
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
Comment 3 Ray Strode [halfline] 2008-11-18 09:57:13 EST
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.
Comment 4 Jeremy Katz 2008-11-18 10:25:54 EST
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)
Comment 5 Jeremy Katz 2008-11-18 11:21:08 EST
(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
Comment 6 Ray Strode [halfline] 2008-11-18 13:59:00 EST
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...
Comment 7 Jeremy Katz 2008-11-18 14:09:21 EST
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.
Comment 8 Ray Strode [halfline] 2008-11-18 14:20:12 EST
if you run with --g-fatal-warnings should dump a core file i think (unless there are other warnings before it)
Comment 9 Ray Strode [halfline] 2008-11-18 14:22:33 EST
grr, scratch that.  gdk_x_error has:

#ifdef G_ENABLE_DEBUG     
          g_error ("%s", msg);
#else /* !G_ENABLE_DEBUG */
          g_fprintf (stderr, "%s\n", msg);

          exit (1);
#endif /* G_ENABLE_DEBUG */

so it will only dump core if gtk is built with --enable-debug....
Comment 10 Jeremy Katz 2008-11-18 14:36:58 EST
... 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 :/
Comment 11 Jesse Keating 2008-11-18 17:48:59 EST
I'm less inclined to consider this a blocker then.  I'm moving over to Target given our current timeline.
Comment 12 Bug Zapper 2008-11-26 00:32:26 EST
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:
Comment 13 gary 2009-02-28 19:56:34 EST
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).
Comment 14 Bug Zapper 2009-11-18 03:53:22 EST
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: 
Comment 15 Bug Zapper 2009-12-18 01:52:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.