GNOME Bugzilla – Bug 353226
at-spi-registryd Crashes frequently
Last modified: 2006-09-25 11:27:05 UTC
Forwarded from: https://launchpad.net/distros/ubuntu/+source/at-spi/+bug/56452 'at-spi_at-spi-registryd' crashes when trying to start an AT application like gnopernicus. Program received signal SIGSEGV, Segmentation fault.
+ Trace 71115
Thread NaN (LWP 7815)
Thread 1 (Thread -1219672400 (LWP 7815))
Look at this fragment (from above):
+ Trace 71117
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.
The reporter said it was gnopernicus crashing, some other reporter mentioned orca. We have no relevant patches to at-spi in Edgy.
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.
Similar backtrace on edgy when opening a test user desktop and closing it without having user or started any application: "Program received signal SIGSEGV, Segmentation fault.
+ Trace 72401
Thread 47467472851152 (LWP 5097)
The bug is NEEDINFO, what information ar you asking for?
Sebastien: your stack trace is interesting and may shed some light. However it isn't severity==critical since it's crash-on-exit. The initial report from Daniel is probably critical in severity since it doesn't seem to refer to shutting down the desktop (Note that the linc connections are being broken at the same time, in both examples.) I still think the root cause is not shown in these stack traces, though.
It'd be nice to hear if it crashes-on-exit in older versions and other distributions too. My personal guess is that it's not an "Edgy problem", but that in Edgy we just found out with apport catching the trace.
Hi Daniel: the problem you originally reported seems to be unique to Edgy, at least if I understood correctly that it happened while the desktop was active, when trying to launch gnopernicus or other AT. Its stack trace does look a lot like the one Sebastien posted in comment #4 however. We've been hearing about problems with Edgy on the list, but no one in Sun is seeing them on either Solaris or other distros we're testing, it seems.
At-spi-registryd receives a request to add an application to its list of accessible apps anytime an accessible app starts; this will happen in any accessible desktop session, even if no "productivity apps" are loaded, since nautilus, the panel, and other apps are still active. When such a request is received, at-spi-registryd sets up a listener for the ORBit connection to that application via ORBit_small_listen_for_broken(). If the application's ORB connection is broken (usually indicating that the application has died, SEGV or similar), then the "abnormal_application_termination" function is called. The stack traces above show that this is happenning, which means that some other apps are crashing and burning. It's not clear why this is taking the registry down with it - possibly there is a codepath in the post-abnormal_application_termination logic in the registry that isn't as robust as we'd like... however it's still a smoking gun that indicates a serious problem elsewhere, outside of at-spi-registryd, otherwise those apps would not be breaking their ORBit2 connection... I can investigate the former (why the registry goes down when this happens), but I can't tell anything from the info associated with this bug report about why the apps are dying in the first place (in the case of the initial comment's bug report).
Created attachment 73003 [details] [review] patch to prevent ref/unref of defunct application object when an app is removed from the desktop's accessible children list
The reporters of the bug experience no crashes anymore with the bug applied.
Thanks for your work on this!
Daniel: thanks for your work in finding, testing, and obtaining stack traces. It makes my work a lot easier/more effective! Sorry about these lingering crashers, I hope we can flush them all out one by one.