Bug 318911

hmm, very bizarre?

Do you have GtkModulesList set in /etc/gdm/custom.conf ?

If so, can you try remove modules from that list one by one (they're separated
by colons) to see which one is causing the problem?

If you don't have GtkModulesList set, would you mind setting it to the default
value (which is in /usr/share/gdm/defaults.conf) and working from that?

Adding to F8Blocker.

> hmm, very bizarre?

Agreed.

> Do you have GtkModulesList set in /etc/gdm/custom.conf ?

Nope.  Although you will get one from /usr/share/gdm/defaults.conf
unless its turned off with 'AddGtkModules=false'.  BTW - selinux
is not in the picture as it is turned off.

OK, the default GtkModulesList is
gail:atk-bridge:/usr/lib64/gtk-2.0/modules/libkeymouselistener

If I will drop from there atk-bridge then gdm starts as before with
Greeter=/usr/libexec/gdmlogin.  OTOH I will leave only atk-brige
on GtkModulesList then gdm attempts to start and immediately crashes
(as opposed to spinning a cursor with a default module list).
In /var/log/messages I am then finding:

gdm-binary[2759]: ERROR: file accessible.c: line 554 (spi_accessible_construct):
assertion failed: (o)#012aborting...
gdm-binary[2702]: WARNING: failsafe dialog failed (inhibitions: 0 0)

and similar.

moving to at-spi for now

Matthias, have you done any at-spi changes recently?

no

I failed to reproduce this so far. gdmlogin works fine here, with a11y modules 

> gdmlogin works fine here

It worked fine here too - until very recent changes and I still cannot
figure out what triggered troubles.

ERROR messages quoted in comment #2 I observed _only_ when I had
single atk-bridge on GtkModulesList.  With a default list gdm just
loops on 'rt_sigaction()' as originally reported.

After applying 20071005 changes I tried with an updated gdm-2.20.0-14.fc8.
With

GtkModulesList=atk-bridge

in custom.conf (and modules enabled) I got immediately in /var/log/messages

gdm-binary[2529]: ERROR: file accessible.c: line 554 (spi_accessible_construct):
assertion failed: (o)#012aborting...
gdm-binary[2457]: WARNING: failsafe dialog failed (inhibitions: 0 0)
gdm-binary[2530]: ERROR: file accessible.c: line 554 (spi_accessible_construct):
assertion failed: (o)#012aborting...
gdm-binary[2457]: WARNING: failsafe dialog failed (inhibitions: 0 1)
gdm-binary[2531]: Gtk-WARNING: Ignoring the separator setting

gdm attempts to start, crashes before displaying anything, tries
again, crashes and brings alert that "The greeter application appears
to be crashing. Attempting to use a different one."  After a click on
"OK" it goes in the same cycle - silent crash, crash with an alert -
and da capo al fine.

One solution is the same as before - i.e. drop atk-bridge from
GtkModulesList.

Actually after a closer look the situation with gdm-2.20.0-14.fc8
is a bit more "interesting".  With Greeter=/usr/libexec/gdmlogin
and AddGtkModules=true here are findings expanding on comment #8:

With GtkModulesList set to gail:/usr/lib64/gtk-2.0/modules/libkeymouselistener
gdm starts but does not accept any keyboard input in gdmlogin window.

With only /usr/lib64/gtk-2.0/modules/libkeymouselistener gdm justs
spins "busy" cursor on a dark blue background and does not go any
further.

With only gail everything looks normal and login is possible.

Still fine for /usr/lib64/gtk-2.0/modules/libkeymouselistener:gail
and gail:/usr/lib64/gtk-2.0/modules/libkeymouselistener:gail and
also for an empty modules list.  AddGtkModules=false solves the
issues too.

List gail:/usr/lib64/gtk-2.0/modules/libkeymouselistener was fine
with gdm-2.20.0-13.fc8 (or maybe this is something in a big pile
of other updates which showed up today).

Somehow this does not smell like only at-spi problem.

Still can't reproduce this on i386. gdmlogin works fine here with any set of
modules I give it.

> Still can't reproduce this on i386.

Hm, maybe this is x86_64 specific? My machine is of that sort
(as indicated by "/usr/lib64/gtk-2.0/modules/... path :-).

Ray just tried on a fresh x86-64 rawhide install and failed to reproduce...

are you running any sort of unusual X server?  What's the output of xdpyinfo
once you've logged in?

Created attachment 221621 [details]
an output from xdpyinfo

> are you running any sort of unusual X server?

Only if xorg-x11-drv-ati-6.7.195-1.fc8.x86_64 driving
ATI Radeon 9250 5960 (AGP) card can be deemed "unusual".

> What's the output of xdpyinfo once you've logged in?

Attached.

I will try to see later if I can get more or/and better information.
OTOH I wonder if this is not somewhat related to bug 224611.
Numerous people are hit by that.

I installed gdm-debuginfo-2.20.0-14.fc8 and tried to run gdm with
the following .gdbinit file:

set detach-on-fork off
directory /usr/src/debug/
directory /usr/src/debug/gdm-2.20.0
directory /usr/src/debug/gdm-2.20.0/utils
directory /usr/src/debug/gdm-2.20.0/pixmaps
directory /usr/src/debug/gdm-2.20.0/pixmaps/24x24
directory /usr/src/debug/gdm-2.20.0/gui
directory /usr/src/debug/gdm-2.20.0/gui/modules
directory /usr/src/debug/gdm-2.20.0/gui/greeter
directory /usr/src/debug/gdm-2.20.0/daemon
directory /usr/src/debug/gdm-2.20.0/common
run

This is only producing a lot of warnings in such style:

warning: Missing the separate debug info file:
/usr/lib/debug/.build-id/b4/25f74ef51bcb48a6b08cf3c03466c91f299eb8.debug

and it is not going very far.  A full output is attached.
BTW - all these complaints are about something which is really missing
as /usr/lib/debug/.build-id/ includes only these directories:
1e  33  4f  60  63  6f  7c  b1  b5  c6  e2  ed  f1  f7

If I am trying to attach gdb to already running gdm-binary processes
then I am consistently getting something like this:

[Switching to process 19669]
(gdb) where
#0  0x000000319b69a622 in fork () from /lib64/libc.so.6
#1  0x000000000040d065 in main (argc=1, argv=0x7fffeecb0558) at gdm.c:191
#2  0x000000319b61e0b4 in __libc_start_main () from /lib64/libc.so.6
#3  0x000000000040ae89 in _start ()
(gdb) f 1
#1  0x000000000040d065 in main (argc=1, argv=0x7fffeecb0558) at gdm.c:191
191             pid = fork ();
(gdb) l
186     gdm_daemonify (void)
187     {
188             FILE *pf;
189             pid_t pid;
190
191             pid = fork ();
192             if (pid > 0) {
193                     const char *pidfile = GDM_PID_FILE;
194
195                     errno = 0;

Not that surprising but it does not tell me very much.

OTOH with 'GtkModulesList=atk-bridge' I collect consistenly in
/var/log/messages:

gdm-binary[19969]: ERROR: file accessible.c: line 554
(spi_accessible_construct): assertion failed: (o)#012aborting...
gdm-binary[19857]: WARNING: failsafe dialog failed (inhibitions: 0 0)
gdm-binary[19970]: ERROR: file accessible.c: line 554
(spi_accessible_construct): assertion failed: (o)#012aborting...
gdm-binary[19857]: WARNING: failsafe dialog failed (inhibitions: 0 1)
gdm-binary[19971]: Gtk-WARNING: Ignoring the separator setting

as described before.  Any ideas where I can dig?

Created attachment 222011 [details]
an output from a debug attempt with gdm

Retested with gdm-2.20.0-16.fc8 and 20071012 changes.
With Greeter=/usr/libexec/gdmlogin and a default GtkModulesList
gdm started to work for me once again.  OTOH if I will do
GtkModulesList=atk-bridge then I have an immediate gdm crash
and "ERROR: file accessible.c: line 554" messages in abundance.
Other module combinations with 'atk-brigde' skipped seem to work
fine.

I have no idea what accounts for observed behaviour changes.  That
module combinations/ordering may affect the total outcome I noticed
earlier.  It is quite possible that troubles caused by an 'atk-brigde'
presence were there for a long time and I simply never noticed that
until I started to mess with a configuration of GtkModulesList.

Ok, i have now reproduced the crash you are seeing. You can simply do 

GTK_MODULES=atk-bridge gtk-demo

to reproduce it in a more accessible (!) situation.

I guess the short answer is: don't do that, then.

Of course, we may want to make things not crash due to bad settings of
GTK_MODULES, but imo, this is not a release blocker.

Filed upstream: http://bugzilla.gnome.org/show_bug.cgi?id=486211

> I guess the short answer is: don't do that, then.

Well, the whole reason why I started all these experiments with module
lists was that with a default one ("don't do") gdm suddenly stopped
working.  Currently it works again but it would be nice to know why
both things happened.