Bug 206323

I haven't been able to capture any at-spi-registryd crashes so far. Is this on
a 64bit arch ?

> Is this on a 64bit arch ?

Yes, indeed.  I thought that this is quite clear from addresses
in backtraces; but I do not have any information about an i386
behaviour.

I am not aware of any problems of that sort with a preceding
version of at-spi.

Which arch ? The "Hardware" combo up top is there for a reason...

The arch is x86_64.

But after the current update to ORBit2-2.14.3-3.fc6.x86_64 when
trying once again:

gdb --args /usr/libexec/at-spi-registryd \
--oaf-activate-iid='OAFIID:Accessibility_Registry:'

I got this time "Program exited normally".  OTOH doing that with
a remote display instead of a local one ended up with this in gdb:

Bonobo-Activation-ERROR **: This process has not registered the required OAFIID
your source code should register 'OAFIID:Accessibility_Registry:'. If your code
is performing delayed registration and this message is trapped in error, see
bonobo_activation_idle_reg_check_set.
aborting...

Program received signal SIGABRT, Aborted.
[Switching to Thread 46912496270256 (LWP 10072)]
0x000000322e6301a5 in raise () from /lib64/libc.so.6

Is this expected?

I also did not see new core files; at least so far.

Now, for a change, with the same version of at-spi I am collecting
in /var/log/messages lines like that:

at-spi-registry[7736] trap stack segment rip:359083ae95 rsp:7fffe50eff00 error:0

These happen at different times; most probably after
"gconfd (root-2890): Exiting" although not always.  The first
showed up on September 19th and it is far from obvious to me
an installation of what could be instrumental to trigger that.

"rip:325683ae95" is always the same.

at-spi actually dumps cores again (if allowed) but even with
at-spi-debuginfo installed 'gdb -c core.3127' says only:

Core was generated by `/usr/libexec/at-spi-registryd
--oaf-activate-iid=OAFIID:Accessibility_Registry:'.
Program terminated with signal 6, Aborted.
#0  0x000000352dc301b5 in ?? ()

and a backtrace does not show any symbols at all; like that:

(gdb) where
#0  0x000000352dc301b5 in ?? ()
#1  0x000000352dc31b20 in ?? ()
#2  0x00007fff5828cb08 in ?? ()
#3  0x00007fff5828bdf0 in ?? ()
#4  0x00007fff5828bd60 in ?? ()
#5  0x00007fff5828be20 in ?? ()
#6  0x0000000200000000 in ?? ()
#7  0x00007fff5828be30 in ?? ()
#8  0x00007fff5828eb37 in ?? ()
#9  0x000000000000001d in ?? ()
#10 0x000000352dd18d13 in ?? ()
#11 0x0000000000000003 in ?? ()
#12 0x00007fff5828be2a in ?? ()
#13 0x0000000000000006 in ?? ()
#14 0x000000352dd18d17 in ?? ()
#15 0x0000000000000002 in ?? ()
#16 0x00007fff5828be1e in ?? ()
#17 0x0000000000000002 in ?? ()
#18 0x000000352dd19105 in ?? ()
#19 0x0000000000000001 in ?? ()
#20 0x000000352dd18d13 in ?? ()
#21 0x0000000000000003 in ?? ()
#22 0x0000000000000020 in ?? ()
#23 0x0000000000000000 in ?? ()

Created attachment 137486 [details]
gdb output from at-spi produced core

The most recent cores are actually more interesting.  Crashes
happen at registry-main.c:82 ( a call to 'bonobo_main()' ).
A sample is a bit long to paste it here so it is attached.

Different signals are produced over time so maybe something is scribbling
over a stack?  A catch from today is segfault.  Here we go:

Core was generated by `/usr/libexec/at-spi-registryd
--oaf-activate-iid=OAFIID:Accessibility_Registry:'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000003da8e3a336 in IOP_profiles_sync_objkey ()
   from /usr/lib64/libORBit-2.so.0
(gdb) bt
#0  0x0000003da8e3a336 in IOP_profiles_sync_objkey ()
   from /usr/lib64/libORBit-2.so.0
#1  0x0000003da8e3090a in ORBit_object_get_connection ()
   from /usr/lib64/libORBit-2.so.0
#2  0x0000003da8e2ef02 in ORBit_small_invoke_stub ()
   from /usr/lib64/libORBit-2.so.0
#3  0x0000003da9e0c788 in Bonobo_Unknown_unref ()
   from /usr/lib64/libbonobo-activation.so.4
#4  0x0000000000408271 in desktop_remove_application (
    desktop=<value optimized out>, index=6, data=<value optimized out>)
    at registry.c:156
#5  0x0000003d9e80b16a in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#6  0x0000003d9e81b3bd in g_signal_override_class_closure ()
   from /lib64/libgobject-2.0.so.0
#7  0x0000003d9e81c826 in g_signal_emit_valist ()
   from /lib64/libgobject-2.0.so.0
#8  0x0000003d9e81ca03 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#9  0x00000000004045d9 in spi_desktop_remove_application (desktop=0x632d80,
    app_ref=0x655480) at desktop.c:353
#10 0x0000003da8e45ee5 in link_connection_get_type ()
   from /usr/lib64/libORBit-2.so.0
#11 0x0000003da8e45f3d in link_connection_get_type ()
   from /usr/lib64/libORBit-2.so.0
#12 0x0000003da8e4639b in link_connection_disconnect ()
   from /usr/lib64/libORBit-2.so.0
#13 0x0000003da8e46442 in link_connection_state_changed ()
   from /usr/lib64/libORBit-2.so.0
#14 0x0000003da8e2ba8e in giop_connection_handle_input ()
   from /usr/lib64/libORBit-2.so.0
#15 0x0000003da8e46890 in link_connection_state_changed ()
   from /usr/lib64/libORBit-2.so.0
#16 0x0000003d9e42cf44 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#17 0x0000003d9e42fd7d in g_main_context_check () from /lib64/libglib-2.0.so.0
#18 0x0000003d9e43008a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#19 0x0000003dab62d0e6 in bonobo_main () from /usr/lib64/libbonobo-2.so.0
#20 0x0000000000407f69 in main (argc=3, argv=<value optimized out>)
    at registry-main.c:82
#21 0x0000003d9bc1da44 in __libc_start_main () from /lib64/libc.so.6
#22 0x0000000000404259 in _start ()
(gdb) f 20
#20 0x0000000000407f69 in main (argc=3, argv=<value optimized out>)
    at registry-main.c:82
82            bonobo_main ();
(gdb) f 9
#9  0x00000000004045d9 in spi_desktop_remove_application (desktop=0x632d80,
    app_ref=0x655480) at desktop.c:353
353           g_signal_emit (G_OBJECT (desktop),
spi_desktop_signals[APPLICATION_REMOVED], 0, idx);
(gdb) p idx
$1 = 4
(gdb) p desktop
$2 = (SpiDesktop *) 0x632d80
(gdb) p *desktop
$3 = {parent = {parent = {parent = {base = {g_type_instance = {
            g_class = 0x63de80}, ref_count = 3, qdata = 0x0}, priv = 0x63c9a0,
        object_signature = 44786, servant = {_private = 0x63ca00,
          vepv = 0x63d020}, dummy = 0, corba_objref = 0x63e6b0,
        servant_signature = 12206}, gobj = 0x61e680}}, applications = 0x64a0c0}
(gdb) f 4
#4  0x0000000000408271 in desktop_remove_application (
    desktop=<value optimized out>, index=6, data=<value optimized out>)
    at registry.c:156
156       Accessibility_Accessible_unref (a, &ev);
(gdb) l
151       */
152       spi_init_any_nil (&e.any_data,
153                         e.source,
154                         Accessibility_ROLE_DESKTOP_FRAME,
155                         "");
156       Accessibility_Accessible_unref (a, &ev);
157       Accessibility_Registry_notifyEvent (BONOBO_OBJREF (registry),
158                                           &e, &ev);
159       Accessibility_Desktop_unref (e.source, &ev);
160       CORBA_exception_free (&ev);
(gdb) p a
$4 = (Accessibility_Accessible) 0x652fe0
(gdb) p ev
$5 = {_id = 0x0, _major = 0, _any = {_type = 0x0, _value = 0x0,
    _release = 0 '\0'}}
(gdb) p &ev
$6 = (CORBA_Environment *) 0x7fffb4e92d70

After latest updates at-spi-registryd does not drop cores anymore.
This already happened in the past so, unless it is known what was the
problem and that it is fixed, I would rather wait and see for a while.

The most recent core from at-spi-registryd I have from 2006-10-25 with
a timestamp right after at-spi-1.7.12-1.fc7 was installed.  That most
likely means that at that moment at-spi-1.7.11-2.fc6 was still in use.
In the last week after that I did not get any new core files from
programs in 'at-spi' package.  I guess that we may assume that the
problem is fixed - even if it would be so much nicer to have the
issue identified.

The catch is that at-spi-1.7.11-2.fc6 is used in FC6 release and so far
no updates.  OTOH I do not have at the moment such FC6 installation on
which I could check for a presence or absence of this bug.  So what
do you want to do with a Status of this bug?  Change to FC6, close,
someting else?