Hal issues with the new D-Bus
danny.kukawka at web.de
Fri Nov 3 00:49:33 PST 2006
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
> 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:
> 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.
> 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 these?
> 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?
More information about the hal