Hal issues with the new D-Bus
John (J5) Palmieri
johnp at redhat.com
Fri Nov 3 12:42:57 PST 2006
On Fri, 2006-11-03 at 09:49 +0100, Danny Kukawka wrote:
> On Friday 03 November 2006 03:56, John (J5) Palmieri wrote:
> > I was doing a D-Bus release today and ran into issues with hal
> > 0.5.8.1-4. It seems that gnome-power-manager was segfaulting hald. I
> > was unable to track down the segfault but am holding off releasing the
> > new D-Bus until I can make sure it is not a problem with libdbus itself.
> > A couple of things I did notice was that dbus_connection_close was
> > called a few times in these files
> >
> > tools/hal-device.c
> > tools/lshal.c
> > hald/linux/addons/addon-cpufreq.c
> >
> > You are only supposed to close connections you own otherwise you are
> > just supposed to unref shared connections. Older versions of D-Bus
> > would just throw a warning. The newer one asserts. Please take these
> > out if they do not belong.
>
> There is already a patch commited to git HEAD:
> http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=c85e02d58d6503b494bb4c8584a7c44ac6923208
>
> > There is also an issue with libhal_device_add_capability in
> > libhal/libhal.c. hald/linux/addons/addon-cpufreq.c asserts in
> > dbus_init. This is because you send in a NULL for error and then in
> > libhal_device_add_capability check dbus_error_is_set (error) which will
> > assert if error == NULL. You can either pass error objects to the API
> > or check if error == NULL before calling dbus_error_is_set.
>
> Should be easy to fix. We should put a macro to libhal to check always if
> error != NULL before use the related D-Bus functions.
Actually I would just send in the error and check or print it out. It
is a few extra lines of code but much better to get into the habit.
>
> > Also not related to D-Bus, but I get a lot of Warning: Error while wite
> > r->input () to stdin_v. There is a typo s/wite/write and should I be
> > getting
> >
> > Attached is the output of running hald --daemon=no --verbose=yes, when
> > running gnome-power-manager it crashes.
>
> IMO it's maybe better to run hald
> with --daemon=yes --verbose=yes --use-syslog. The behavior with --daemon=no
> can maybe differ from the normal behavior as daemon.
>
> > in hald_dbus_filter_handle_methods it seems that
> > helper_interface_handlers is corrupt or at least the data (hih) is.
> >
> > Can someone grab the D-Bus sources from CVS and help debug this?
Found the bug. Calling g_slist_remove on a link caused the link to not
be removed but the data was freed. Patch attached calls
g_slist_remove_link.
--
John (J5) Palmieri <johnp at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hal-remove-link.patch
Type: text/x-patch
Size: 855 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/hal/attachments/20061103/2a6aa0f2/hal-remove-link.bin
More information about the hal
mailing list