Edgy: at-spi Crashes frequently (crash reports no longer necessary)

Happens for me here. Attaching my backtrace as well.

Crash log

more debug logs

Confirmed by Luke

Thanks for your bug report. It'd help if you'd attach a backtrace of the crash. http://wiki.ubuntu.com/Backtrace would help.

Gdb session attached.

Luke,

Do you have the problem described in https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/52405 ?
removing /etc/xdg/menus/debian-menu.menu is a fix described there, which seemed to resolve both the panel problem and the at-spi problem for me.

I have this problem (AT-SPI crashes on boot), and I do not have /etc/xdg/menus/debian-menu.menu

I also have this problem periodically, and I don't have /etc/xdg/menus/debian-menu.menu either.

I think Orca is causing it's crash on my machine.

Wrong assumption, ignore it.

Thanks Luke for your backtrace, I forwarded it upstream. It's still lacking orbit and bonobo debug symbols, but let's see what upstream says about it: http://bugzilla.gnome.org/show_bug.cgi?id=353226

 Comment #1 from <email address hidden> (at-spi developer, points: 23)
2006-08-28 13:29 UTC [reply]

Look at this fragment (from above):

#7 0xb77cbeae in IA__g_signal_emit (instance=0x805f690, signal_id=18,
detail=0) at gsignal.c:2241
#8 0x0804c219 in spi_desktop_remove_application (desktop=0x805f690,
app_ref=0x8088c88) at desktop.c:353
#9 0x0804bf11 in abnormal_application_termination (object=0x8070908,
app=0x8090550) at desktop.c:278
#10 0xb7e2bd74 in link_connection_get_type () from /usr/lib/libORBit-2.so.0
#11 0xb7e2bdc4 in link_connection_get_type () from /usr/lib/libORBit-2.so.0
#12 0xb7e2c24c in link_connection_disconnect () from /usr/lib/libORBit-2.so.0
#13 0xb7e2c303 in link_connection_state_changed () from
/usr/lib/libORBit-2.so.0
#14 0xb7e1092d in giop_connection_handle_input () from /usr/lib/libORBit-2.so.0
#15 0xb7e2c71d in link_connection_state_changed () from

Looks like some other app is crashing weirdly with a bad connection to
at-spi-registryd. What app is that?

This problem seems like it's distro-specific, I suspect a config problem, as no
similar crashing behavior is reported.

Comment #3 from <email address hidden> (at-spi developer, points: 23)
2006-08-28 13:57 UTC [reply]

Hi Daniel:

Yes we've heard that Edgy has problems with a11y but we don't know what's wrong
yet. The "application" crash I refer to doesn't appear to be an assistive
technology but it might be, hard to know. But in any case I doubt that the
stack trace above points to the root cause.

Since the behavior has been seemingly unpredictable, I took some time today trying to reliably reproduce it. Here's what I have come up with. Not sure if it helps....

1. Boot
2. Launch Orca from the Applications menu
3. Quit Orca with Insert Q

At this point Python crashes (attempted to get a backtrace -- attached). 90% of the time, At-spi-registryd does not immediately crash (no dialog; nothing appearing in /var/crash). The other 10% of the time it does.

4. Reboot

at-spi-registryd crashes (log appears in /var/crash).

I can reliably reproduce this on two machines.

Crash here too

Hey Will,

Am Dienstag, den 29.08.2006, 10:48 -0400 schrieb Willie Walker:
> This problem has (hopefully) been fixed in pyorbit 2.14.1. I notice
> that the package that comes with Edgy is pyorbit 2.14.0, so this is
> likely why we still see the SEGV when Orca exits.

thanks a lot for pointing out. I wonder why it wasn't on the GNOME
release list (or why I missed it).

Can everybody having the crash try with the new pyorbit (once it is in
the archive)?

Have a nice day,
 Daniel

With the new pyorbit, I no longer get the python crashes I mentioned earlier. However, when I reboot I still get the report of at-spi-registryd crashing.

I had a crash on closing synaptic

Heres another:

Occurs at every boot.

I do use compiz for the eye candy, perhaps others do so as well?

No, I don't use compiz.

Yes this happens often to me as well. I'm using Edgy up-to-date. I've attached my crash report.

I use compiz ... but i think i was getting crash report prompts even without compiz or xgl active.

Another crash report... I don't use compiz.

Hereś another

Hi,

This crash happens when I close Xchat. The crash log is attached below.

upgrade and at-spi failed on reboot.

attached bug

me too. Hope my log is helpful.

Here is a crash dump as well, crash happens when i login to gnome.

This started after I tested Orca

Another crash log

crash log

Yet another crash log

Got a crash too after trying Orca. None before.

my crash log.

Here a problem report, I just click on the icon and it crashed...

while opening an image in F-Spot

Updating the repositories in Software Sources applet.

What information is still needed for this bug?

At 2:30 AM +0000 on 9/11/06, Andrew Conkling wrote:
> What information is still needed for this bug?
>
> --
> Edgy: at-spi Crashes frequently
> https://launchpad.net/bugs/56452

I have no idea how to answer this question about more information.
I've switched back to using Dapper....not feeling up to testing.

chriss

We need more backtraces, especially with debug symbols. Trying it yesterday, I couldn't reproduce the issue. http://wiki.ubuntu.com/DebuggingProgramCrash and http://wiki.ubuntu.com/Backtrace might help there.

Having problems recompiling the at-spi package as instructed in the wiki, it complains about missing files.

I did however manage to make a valgrind log. Hope this can be of some use.

Just a note, this is a fresh installation from the daily snapshot image, and i could reproduce this crash by running Orca, saying yes all way through in first run, restart and there we go, crash comes every time.

Builld log where it failes in case this would be relevant.

Managed to catch an strace as well.

Ok... thanks for all the crash reports, but they're not of much use if they don't contain a backtrace, preferrably one with debug symbols.

I played with orca (and a11y turned on) extensively now on an amd64 and a i386 live CD, both current Edgy - no breakage whatsovever. Can anybody please give me instructions how to reproduce and please try this with a new user. I think it was Bill who reckoned it might be a configuration problem.

*For me*, the crash nearly always appears on reboot and not before. Logging out and back in is not sufficient -- which rules out live CD replication. All I have to do is launch Orca, quit Orca, and reboot. I can reproduce this 100% of the time on all three of my Edgy boxes. I'd get a backtrace if I could, but I'm not sure how I'd go about doing so given that the crash occurs on reboot. But I'm quite new to all of this. Therefore, if there's a way to pull the backtrace off under these conditions, do please let me know how, and I shall do it.

In terms of trying it with a new user:

Under installed Edgy i386, latest updates, Orca from CVS HEAD, Fonix DECtalk installed:

1. Create a new user -- give the new user permission to administer the system (so that the crash report icon appears upon reboot). Leave all other settings alone.
2. Log in as the new user
3. Run Orca and go through the setup process
4. Log out, then back in
5. Launch Orca
6. Quit Orca
7. Reboot and log back in as new user

Crash report icon appears.

On 9/12/06, Joanie <email address hidden> wrote:
> 3. Run Orca and go through the setup process
> 4. Log out, then back in
> 5. Launch Orca

For me, these three steps are sufficient.

Please all try to get a backtrace of this - it's crucial to get the bug fixed - http://wiki.ubuntu.com/Backtrace does explain how.

Hi Daniel. Please forgive my ignorance/newbieness but....

The page you link to has you do the following:
1. Start GDB and attach it to the process that crashes
2. Continue the process
3. **When the process crashes** retrieve a backtrack of the crash

The problem I'm having is that the process doesn't crash **until I reboot**. It just keeps running. Therefore, I do not see how I can use this method to obtain the backtrace.

I did try rebooting into single-user mode figuring that I could do the above and then launch X and hopefully get a backtrace that way. But it seems that at-spi-registryd doesn't get a PID until you launch GDM -- and by that point the crash has taken place.

The page you link to links to "Another useful how-to". Bug Buddy never appears with the at-spi crash, so I'm looking at "Obtaining a stack trace using just GDB." The section "Obtaining a stack trace for an applet using just GDB" seems to be the relevant one. I have tried the procedure outlined there (using /usr/lib/at-spi/at-spi-registryd). All that does is cause at-spi-registryd to run and exit. Nothing crashes.

So what am I missing/doing wrong?

I do want to help by getting a backtrace, but I'm afraid I'm going to need more explicit directions. My apologies, and thanks much in advance for your help.

What I tried was: reboot, wait for gdm to come on, type gdb -p $(pidof at-spi-registryd) - don't hit enter yet, ctrl-alt-f7, login, switch to ctrl-alt-f1, press enter -- I couldn't see it crashing.

Duh. I have automatic login enabled. I always forget about that... I just disabled it and tried again.

*Without accessible login enabled*, the at-spi-registryd process does not yet exist when I do as you suggest.

*With accessible login enabled*, the first thing I see (before I can log in) is a dialog stating, "The greeter application appears to be crashing. Attempting to use a different one." Does that mean that at-spi-registryd has already crashed??? Regardless, I then tried to attach to each of the 2 at-spi-registryd processes that exist at that point and log in. Neither of those processes crashed, but I once again had the crash report icon in the notification area -- which leads me to believe that at-spi-registryd crashed as soon as gdm attempted to present the login dialog.

Thanks for your help!! If you have other things you'd like me to try, just let me know.

Okay, I just re-read what you suggested -- this time more carefully. :-)

I disabled accessible login and followed your instructions. Now at-spi-registryd isn't crashing, but I cannot get past the splash screen either (and I did type "continue" at the gdb prompt).

Update: It's not crashing upon reboot; it's crashing upon logging off/shutting down. My bad!

I don't get much in the way of a backtrace, but I do get a segmentation fault. Don't see a core file getting dumped, however. Suggestions?

One more log.

The crash icon appeared just after GNOME starting.

crash when restarting gnome

crashes for me too

Crashes immediately after login.

The crash logs are useless, if they don't contain backtraces.

What about the valgrind log and the strace i provided earlier?

Also we cannot produce a backtrace, cause we can't compile a package with debug information, there is an error in the source deb file. Also send the log of this error.

Maybe you can post a deb package with debug information so we can provide you this with backtrace info?

During the valgrind and strace sessions it seemed that at-stpi-registryd didn't crash, so it's not really helpful.

I doubt that catching a backtrace for the crash with or without debugging symbols makes a difference - up until now nobody was able to catch a backtrace in the wildlife, but sure - I could make debug packages for at-spi, no problem.

On 9/15/06, Daniel Holbach <email address hidden> wrote:
> I doubt that catching a backtrace for the crash with or without
> debugging symbols makes a difference - up until now nobody was able to
> catch a backtrace in the wildlife, but sure - I could make debug
> packages for at-spi, no problem.

I don't think I need to tell you howe useful this would be in testing this. :P

The magnificent seb128 followed up on the upstream bug. It all looks like the problem is: at-spi-registryd crashes on logout. This is why nobody of us can get a proper backtrace and why apport complains on a re-login. So I'd rather mark this problem as "very-visible-but-minor".

Same Problem...

Usually shortly after or while logging in from gdm.

I'm going to upload

at-spi (1.7.11-0ubuntu2) edgy; urgency=low
 .
   * debian/patches/10-fix-registryd-crash.patch:
     - apply patch from GNOME bug 353226, hopefully fixes Malone: #56452.

in a bit - it'd be nice to get feedback with it once it's in the archive.

So far so good, Daniel. Thanks!!

Can I take the silence as "Bug is Fixed"?

it seems this bug is fixed, thanks

2006/9/23, Daniel Holbach <email address hidden>:
>
> Can I take the silence as "Bug is Fixed"?
>
> --
> Edgy: at-spi Crashes frequently (crash reports no longer necessary)
> https://launchpad.net/bugs/56452
>

Finally closing bug. YAY

Yes,
Sorry for replying late.

many thnx

Jos

Daniel Holbach wrote:
> Can I take the silence as "Bug is Fixed"?
>
>

yes

On Sat, 2006-09-23 at 06:17 +0000, Daniel Holbach wrote:
> Can I take the silence as "Bug is Fixed"?
>