On Mon, 2009-04-20 at 04:45 +0000, Cody Russell wrote: > We're holding onto a pointer to listener, but we never actually > g_object_ref() it. If that Listener were to unref to 0 before this > AppMenuItem does, then once AppMenuItem hits 0 its finalize is going to > try to disconnect signal handlers using a probably invalid pointer.
Makes sense to add. The listener object is held by the applet itself, and in fact never gets destroyed unless the program exits. But we should keep a reference just in case that changes. > Right now we have a dispose method that's not doing anything. If we > were holding any references to other objects, that would be the right > place to unref them I think. And while we're unreffing them we would > also need to disconnect any signal handlers related to them. Good point, they should be disconnected there. > It kind of looks like some stuff doesn't always get freed or unref'd. > Having finalize() check: > if (priv->type != NULL) > g_free (priv->type); > if (priv->appinfo != NULL) > g_object_unref (priv->appinfo); Yup. Those should be free'd and unreferenced. > I haven't looked into the indicate server to see if this is even > possible, but I'd also feel better if type_cb() would check 'value' > for > NULL before doing going on to g_strdup() and g_strcmp0() using that > pointer. In theory the DBus callback should guarantee that the value should never be NULL. It should, in worst case, be "\0". But, I think it's good to check before the strdup as it'll behave very badly if the value is goofy. > And obviously, whatever I said about listener applies to server as > well. > Server is the thing that actually seems to be causing the crash here > since INDICATE_LISTENER_SERVER_DBUS_NAME(priv->server) is giving us > address out of bounds errors.. The server isn't actually a full GObject, it's a struct so the management of the memory can't really be done by the application menu item. But, that's a good place to look to see if there is anything interesting going on. I'll make sure the signals are all appropriate before the server entry gets destroyed. I committed all of your suggestions to the 0.1 branch, but I don't think that any of them fix this bug specifically. Thanks! -- indicator-applet crashed with SIGSEGV in strcmp() https://bugs.launchpad.net/bugs/362124 You received this bug notification because you are a member of Indicator Applet Developers, which is subscribed to indicator-applet in ubuntu. Status in “indicator-applet” source package in Ubuntu: Confirmed Bug description: Binary package hint: indicator-applet Jaunty-beta 64-bit I'm adding new accounts in Pidgin when the crash occurred. It was after a few notifications (*** is online) [2-4 I think] showed up, then the indicator-applet crashed - twice in a row. Then Pidgin crashed next. Two "reload" pop-up showed up for indicator-applet, when I clicked it both, two indicator-applets showed up in my taskbar. I also reloaded Pidgin after. ProblemType: Crash Architecture: amd64 CrashCounter: 1 DistroRelease: Ubuntu 9.04 ExecutablePath: /usr/lib/indicator-applet/indicator-applet NonfreeKernelModules: nvidia Package: indicator-applet 0.1.6-0ubuntu1 ProcCmdline: /usr/lib/indicator-applet/indicator-applet --oaf-activate-iid=OAFIID:GNOME_IndicatorApplet_Factory --oaf-ior-fd=19 ProcEnviron: LANG=en_PH.UTF-8 SHELL=/bin/bash Signal: 11 SourcePackage: indicator-applet StacktraceTop: strcmp () from /lib/libc.so.6 ?? () from /usr/lib/indicators/1/libmessaging.so g_closure_invoke () ?? () from /usr/lib/libgobject-2.0.so.0 g_signal_emit_valist () Title: indicator-applet crashed with SIGSEGV in strcmp() Uname: Linux 2.6.28-11-generic x86_64 UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare _______________________________________________ Mailing list: https://launchpad.net/~dx-team Post to : [email protected] Unsubscribe : https://launchpad.net/~dx-team More help : https://help.launchpad.net/ListHelp
