GNOME Bugzilla – Bug 637219
Some of gnome applets in panel sometimes crashes on startup
Last modified: 2012-06-25 12:42:27 UTC
Hello, This bug is really annoying me for a couple of weeks (Using Fedora 14). When I start gnome-panel I get applets crash. I can only remove them and place them again (then they works) or try to pkill gnome-panel many times and wait until all applets will load propertly. Here is the output of .xsession_errors: ** (gnome-panel:12675): WARNING **: Failed to load applet ClockAppletFactory::ClockApplet: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.panel.applet.AppletFactory' on object at path /org/gnome/panel/applet/ClockAppletFactory ** Message: applet now embedded in the notification area The same bug filled here but without response - https://bugzilla.redhat.com/show_bug.cgi?id=657451 I can try to debug it more, but somebody must tell me how. Thanks for any help, Filip
Maybe connected to 'my' bug: https://bugzilla.gnome.org/show_bug.cgi?id=637126 And maybe you will get more informations on http://live.gnome.org/GettingTraces/Details (but I do not know how the "symbols"/"debug-info" packages are named in Fedora.)
Does not happen to me on Fedora 14. Please provide more debug info.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
I'm having the same problem, Fedora 14, x86_64, both on an Intel Laptop and on an AMD desktop machine. The applets that usually fail to load are the clock-applet or notification-area-applet from the package gnome-panel-2.32.0.2-2.fc14.x86_64. I have abrt installed, and it does not pop up, so it seems that neither the applets nor the gnome panel itself are crashing. .xsession-errors contains the following messages: ** (gnome-panel:25716): WARNING **: Failed to load applet ClockAppletFactory::ClockApplet: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface `org.gnome.panel.applet.AppletFactory' on object at path /org/gnome/panel/applet/ClockAppletFactory ** Message: applet now removed from the notification area As Filip wrote, I can help debug this but I need to be told what to do. So can you please reopen this bug.
After a quick look at the source code I wonder if this isn't just a simple race condition. It seems that the clock applet registers the applet factory name "/org/gnome/panel/applet/ClockAppletFactory" by doing the following in panel-applet-factory.c: panel_applet_factory_register_service() { panel_applet_factory_register_service( (GBusNameAcquiredCallback)on_name_acquired); } the callback then registers the AppletFactory interface: on_name_acquired() { introspection_data = g_dbus_node_info_new_for_xml( ... "<interface name='org.gnome.panel.applet.AppletFactory'>" ... ); g_dbus_connection_register_object(..., introspection_data); } panel-applet-container.c looks for new applet factory names and has a callback which uses the AppletFactory interface: on_factory_appeared() { g_dbus_connection_call(..., "org.gnome.panel.applet.AppletFactory", ...); } If the "/org/gnome/panel/applet/ClockAppletFactory" becomes visible on dbus before on_name_acquired is called, there is a race here, because in that case on_factory_appeared can be called before on_name_acquired has registered the applet factory interface. One way to test this would be to add a "sleep(1)" just before g_dbus_connection_call and see if that helps.
Yup, that seems to be it. I added a sleep(1) before g_dbus_connection_register_object in on_name_acquired in panel-applet-factory.c and that made all applets fail to load, even applets that I haven't seen fail before. So that shows that there is a race. With the sleep(1) in place, I could make thing works again by adding a sleep(2) before g_dbus_connection_call in on_factory_appeared in panel-applet-container.c. With half a dozen applets loaded it means that gnome panel takes 12 seconds to start, but it works. So as a workaround for now, I've added a usleep(100000) in front of g_dbus_connection_call on my machines, that seems to be enough to avoid the race and doesn't slow down the startup of gnome panel too much.
This has also been reported as affecting gnome-panel in Ubuntu at https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/716714 (and https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/730581, which is a duplicate of that bug). Given Christer Weinigel's recent analysis here, and the 18 additional people registered as experiencing this bug at Launchpad bug 716714, perhaps this bug's status could be changed back from RESOLVED.
Confirming. If there is any more info needed to fix this bug, I'd be happy to provide it.
Since the panel will be available in the fall-back mode in Gnome 3 this bug should definitely be confirmed and addressed. It theoretically affects every installation of Gnome and people who don't know how to reload the panel will go and readd the missing applets after every boot. Since it is a race condition the use of ureadahead, ext4, multi-core cpus or solid-state disks could affect this bug in an unpredictable manner.
I also face this problem on my Linux Mint 11 dual core system but it did not appear yet on my slower single core PC. Can anybody confirm this affects only multi core systems?
It could be, as race conditions are more likely to appear on multi core? Yes, my system is dual core.
Does this still happen in 3.4 or 3.2? If so, which distribution?
Hrm, this is most likely bug 654843, actually. *** This bug has been marked as a duplicate of bug 654843 ***