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:

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

          exit (1);
#endif /* G_ENABLE_DEBUG */
--->8---

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.