I'm not entirely sure this is a bug, but I believe this is worth investigating. This issue appeared related to bug #280251. pilot-link--0.12.2-17.fc8 installs a .fdi file for Palm handhelds. If I plug the Palm before installing the package and then install the package, HAL crashes the next time I plug the Palm. This bug was noticed when installing the package for the first time. However, I can reproduce it with these steps (with pilot-link installed): # mv /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi . # /etc/init.d/haldaemon restart # I know, this is wrong, but it is necessary to reproduce the bug Plug the palm Unplug the palm # mv 19-pam-acl-management.fdi /usr/share/hal/fdi/policy/10osvendor/19-pam-acl-management.fdi Plug the palm Segfault Here is the log of the HAL crash: Jan 11 22:30:19 hamlet kernel: hald[32139]: segfault at 00002aaaaad94000 rip 0000000000410270 rsp 00007fff78937ff0 error 4 Version-Release number of selected component (if applicable): hal-0.5.10-1.fc8.x86_64 hal-cups-utils-0.6.13-2.fc8.x86_64 hal-libs-0.5.10-1.fc8.x86_64 hal-devel-0.5.10-1.fc8.x86_64 pilot-link-0.12.2-17.fc8.x86_64 How reproducible: Deterministic
I've been doing a lot of editing of .fdi files, then re-plugging my Palm to check if everything is working (for bug #280251 comment #100). I'm seeing a similar thing, though it's not always hald, sometimes it's PolicyKit: Feb 10 21:11:27 localhost kernel: hald[2392]: segfault at b7eb0000 eip 080571b6 esp bfdc7820 error 4 Feb 10 21:40:30 localhost kernel: polkit-policy-f[29002]: segfault at 00000000 eip 00be90ac esp bfa56f28 error 4 haldaemon restart gets everything back and working if the above happens.
*** Bug 432644 has been marked as a duplicate of this bug. ***
Rising severity because this bug causes hald to crash and we do not have a workaround. Desktop systems with hald not running is quite unusable.
Can one of the people who can reproduce this please do 1) install gdb, hal-debuginfo 2) attach to hal with gdb 3) reproduce the crash 4) attach the stacktrace here ?
Hello, I have tried to reproduce this bug with gdb attached to hald, but in this case hald does not crash (without gdb attached, it still crashes). Interesting thing is that after detaching gdb from hald (using Ctrl+D), hald dies: 1. # rpm -e pilot-link --nodeps 2. # service haldaemon restart 3. # ps ax | grep hald 14001 ? Ss 0:00 hald 14002 ? S 0:00 hald-runner 14026 ? S 0:00 hald-addon-input: Listening on /dev/input/event5 / dev/input/event11 /dev/input/event10 /dev/input/event1 /dev/input/event6 /dev/ input/event7 14029 ? S 0:00 /usr/libexec/hald-addon-cpufreq 14030 ? S 0:00 hald-addon-acpi: listening on acpi kernel interface / proc/acpi/event 14065 ? S 0:00 hald-addon-storage: polling /dev/sr0 (every 16 sec) 14068 pts/1 S+ 0:00 grep hald 4. # gdb attach 14001 # I have attached to other hald* procesess ^^^ as well, just to see what happens 5. # rpm -ivh pilot-link-0.12.2-19.fc8.x86_64.rpm 6. connect palm to the usb # in this step hald should die (it dies if gdb is not attached) 7. # service haldaemon status hald (pid 14001) is running... 8. Ctrl+D to disconnect gdb 9. # service haldaemon status hald is stopped 10. # ps ax | grep hald 14026 ? S 0:00 hald-addon-input: Listening on /dev/input/event5 / dev/input/event11 /dev/input/event10 /dev/input/event1 /dev/input/event6 /dev/ input/event7 14030 ? S 0:00 hald-addon-acpi: listening on acpi kernel interface / proc/acpi/event 14065 ? S 0:00 hald-addon-storage: polling /dev/sr0 (every 16 sec) 14178 pts/1 S+ 0:00 grep hald Is there any way how to run gdb in some do_not_disturb_running_process_at_all_and_I_mean_it mode? hal-0.5.10-1.fc8.x86_64 hal-cups-utils-0.6.13-2.fc8.x86_64 hal-debuginfo-0.5.10-1.fc8.x86_64 hal-devel-0.5.10-1.fc8.x86_64 hal-info-20071030-1.fc8.noarch hal-libs-0.5.10-1.fc8.i386 hal-libs-0.5.10-1.fc8.x86_64 kernel-2.6.23.15-137.fc8.x86_64 kernel-devel-2.6.23.15-137.fc8.x86_64 pilot-link-0.12.2-19.fc8.x86_64 If there is something else I can test, just attach a comment what to do here or pong me on the chat.
You can also try to look at the core dump that the hal crashed produced. If it doesn't produce a core file, change the ulimit call in /etc/profile to ulimit -c unlimited and reboot then, once hal crashed, gdb /usr/sbin/hald /path/to/core
Created attachment 295429 [details] coredump from hald --daemon=no --verbose=yes #0 0x0000003d32a30ec5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0000003d32a32970 in abort () at abort.c:88 #2 0x0000003d3cc27495 in _dbus_abort () at dbus-sysdeps.c:86 #3 0x0000003d3cc2389a in _dbus_warn_check_failed ( format=0x3d3cc2f700 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:283 #4 0x0000003d3cc167b9 in dbus_message_set_reply_serial (message=<value optimized out>, reply_serial=0) at dbus-message.c:896 #5 0x0000003d3cc19558 in dbus_message_new_error (reply_to=0x608d10, error_name=0x60bb30 "org.freedesktop.Hal.Device.CPUFreq.GeneralError", error_message=0x7fffe55bcc00 "Cannot determine if caller is privileged") at dbus-message.c:1229 #6 0x0000000000402336 in dbus_raise_error (connection=0x608c00, message=0x608d10, error_name=<value optimized out>, format=<value optimized out>) at addon-cpufreq.c:893 #7 0x0000000000403392 in dbus_filter_function (connection=0x608c00, message=0x608d10, user_data=<value optimized out>) at addon-cpufreq.c:539 #8 0x0000003d3cc0e300 in dbus_connection_dispatch (connection=0x608c00) at dbus-connection.c:4350 #9 0x000000375d6094b5 in message_queue_dispatch (source=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at dbus-gmain.c:101 #10 0x000000375922ef53 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #11 0x000000375923224d in ?? () from /lib64/libglib-2.0.so.0 #12 0x000000375923255a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #13 0x0000000000402941 in main (argc=<value optimized out>, argv=<value optimized out>) at addon-cpufreq.c:1331 #14 0x0000003d32a1e074 in __libc_start_main (main=0x402880 <main>, argc=1, ubp_av=0x7fffe55bd468, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffe55bd458) at libc-start.c:220 #15 0x0000000000401f29 in _start ()
So, you seem to be running into some PolicyKit issue. The error comes from addon-cpufreq.c:dbus_is_privileged polkit_result = libhal_device_is_caller_privileged (halctx, udi, CPUFREQ_POLKIT_PRIVILEGE, invoked_by_syscon_name, error); if (polkit_result == NULL) { dbus_raise_error (connection, message, CPUFREQ_ERROR_GENERAL, "Cannot determine if caller is privileged"); goto out; }
PolicyKit maintainer is David Zeuthen so please David could you look at this issue. Thanks a lot.
This seems to be fixed in rawhide (hal-0.5.11-0.2.rc2, hal-info-20080317-1, PolicyKit-0.7-6). Could packages be built for F8?
Hello, I have reproduced this problem (without Palm HW) using: hal-0.5.10-1.fc8.2.x86_64 hal-info-20071030-1.fc8.noarch and found out that: 1. bug is still there 2. it is simple to reproduce without palm, just using any hal-detected HW (e.g. USB stick) Steps to reproduce: # service haldaemon stop # rpm -e --nodeps hal-info # service haldaemon start ### plug in (e.g.) USB stick, hald survives, unplug it (:-)) # rpm -i hal-info-20071030-1.fc8.noarch.rpm ### plug in (e.g.) USB stick, hald dies with (in /var/log/messages): kernel: hald[23188]: segfault at 2aaaaafca000 rip 4102d0 rsp 7fffc6b75240 error 4 # service haldaemon status hald is stopped
This bug seems for me to be fixed in hal-0.5.11-0.git20080304.2.fc9.src.rpm which I rebuilded in F8.
According to steps to reproduce in comment #11 it seems to me like hald can not handle changes of *.fdi files while running.
Linking Novell BZ and fix committed upstream: http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=ab31f06ca5388d4915156d3dac60c3fc52908260 We'll need an errata to fix this for F8/hal-0.5.10
Gustavo: the fix is a patch that's already been committed upstream - could you add the EasyFix keyword to the bug, please?
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.