[6932] in testers
Re: install/update of 9.4
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Mon May 2 11:06:26 2005
Mime-Version: 1.0
Message-Id: <p05230101be9bef810d7d@[18.152.1.192]>
In-Reply-To: <1113927662.8379.16.camel@egyptian-gods.mit.edu>
Date: Mon, 2 May 2005 11:00:13 -0400
To: Greg Hudson <ghudson@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
Cc: Jonathan Reed <jdreed@mit.edu>, testers@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
And, it happened again. This was the first login immediately
following a cold boot of the machine, so I don't quite understand
what dustbuster was doing there:
ps output:
2833 ? S 0:00 /usr/X11R6/bin/X vt07
2881 ? Ss 0:00 /etc/athena/console -display :0.0
-nosession -inputfd
2882 ? Ss 0:00 /bin/sh /etc/athena/login/Xsession 1
2910 ? S 0:00 /bin/athena/tcsh -f /usr/athena/lib/init/xsession
2941 ? S 0:00 metacity
2942 ? S 0:00 /usr/athena/bin/gconftool-2 --spawn
2944 ? S 0:00 dustbuster -s TERM /usr/athena/libexec/gconfd-2 4
2945 ? S 0:00 /usr/athena/libexec/gconfd-2 4
Attaching to process 2945 and backtracing gives:
#0 0x009b87a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x001e753c in __close_nocancel () from /lib/tls/libpthread.so.0
#2 0x00e22397 in resolve_address (address=0x92202b8
"xml:readwrite:/mit/jdreed/.gconf", err=0xbfea0724)
at markup-backend.c:324
#3 0x008f20fd in gconf_backend_resolve_address (backend=0x92211e8,
address=0x92202b8 "xml:readwrite:/mit/jdreed/.gconf",
err=0xbfea0724) at gconf-backend.c:439
#4 0x008f659c in gconf_resolve_address (address=0x92202b8
"xml:readwrite:/mit/jdreed/.gconf", err=0xbfea0724)
at gconf-sources.c:53
#5 0x008f7926 in gconf_sources_new_from_addresses
(addresses=0x9216688, err=0xbfea0760)
at gconf-sources.c:381
#6 0x0804f0cb in gconf_server_load_sources () at gconfd.c:376
#7 0x0804fa93 in main (argc=2, argv=0xbfea0984) at gconfd.c:736
The session finished intializing after I detached from the process, I
don't know whether that was expected or not (I haven't used gdb much
outside of Xcode)
And that dustbuster process was still sticking around, even after
login finished.
-Jon
At 12:21 PM -0400 4/19/05, Greg Hudson wrote:
>On Tue, 2005-04-19 at 10:06, Jonathan Reed wrote:
>> So, this happened again (note that this was logging in without
>> customizations). ps -axwww output is at the end of this e-mail.
>> There were no gconftool-2 processes to strace
>
>In this case, the session was stuck trying to activate
>gnome-settings-daemon, but since that's also a gconf client I assume
>it's the same problem, and gconfd is to blame.
>
>> , and as you can see, there are 3 gconfd-2 processes
>
>The other two are stale. That's a bug (one I thought I had fixed, but
>evidently there's more to it); they're probably not relevant.
>
>> Attaching to the most recent one shows this:
>
>Can you try attaching to it with gdb next time (or this time, if it's
>still tihs time) and getting a backtrace?
>
>I suspect it's just inside its event loop, which isn't very informative,
>but maybe not.
--
-------------------
Jonathan Reed
jdreed@mit.edu
-------------------
