Description of problem:
Installed hal 0.5.10-3.fc8.i386 and hal-info 20080607-2.fc8.noarch from
updates-testing. hald crashes with:
16:38:39.110 [I] osspec.c:439: Done synthesizing events
*** [DIE] device_info.c:rules_match_and_merge_device():1089 : Rule is NULL on jump
16:38:39.111 [D] addon-input.c:486: An error occured, exiting cleanly
Created attachment 310156 [details]
Full output from hald
Does the newer hal-info-20080607-2.fc8 crash the previous version of the hal
package as well?
i.e. is it an addition to the fdi in hal-info triggering a previously existing,
but not triggered, bug? In which case a band aid might be to patch out that
(No crash for me; but need these updated hal/hal-info packages to unblock
After a bit of brute force googling through the long grass of the Debian BTS and
svn, I suspect that this is the patch you need:
The error on crash is the same, at least ;)
It's not applied to the hal-0.5.10 the F8 package pulls in, nor is it in the
Orion: I'm not seeing this crash in the first place - can you give the patch a try?
(I'm very keen to get this hal release working; bug #280251 has been blocking on
a hal update for a loooong time)
That patch made it into upstream hal at:
I can reproduce this bug, this also unfortunately crashes hal for me when I plug
in my Treo:
Jul 9 01:04:54 delpy kernel: hub 1-0:1.0: unable to enumerate USB device on port 1
Jul 9 01:04:55 delpy kernel: usb 2-1: new full speed USB device using uhci_hcd
and address 11
Jul 9 01:04:55 delpy kernel: usb 2-1: configuration #1 chosen from 1 choice
Jul 9 01:04:55 delpy kernel: usb 2-1: New USB device found, idVendor=0830,
Jul 9 01:04:55 delpy kernel: usb 2-1: New USB device strings: Mfr=1, Product=2,
Jul 9 01:04:55 delpy kernel: usb 2-1: Product: Palm Handheld
Jul 9 01:04:55 delpy kernel: usb 2-1: Manufacturer: Palm, Inc.
Jul 9 01:04:55 delpy kernel: usb 2-1: SerialNumber: PalmSN12345678
Jul 9 01:04:55 delpy kernel: hald: segfault at b7def000 ip 08057206 sp
bfd86ce0 error 4 in hald[8047000+54000]
I also see a number of other hal-related messages in /var/log/messages:
Jul 9 00:52:14 delpy kernel: hal-acl-tool: segfault at 9e00000 ip
00a650c7 sp bfffb7e8 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:14 delpy kernel: hal-acl-tool: segfault at 8b00000 ip
00a650c7 sp bfa78838 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:22 delpy kernel: hal-acl-tool: segfault at 8200000 ip
00a650c7 sp bfff65a8 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:22 delpy kernel: hal-acl-tool: segfault at 9500000 ip
00a650c7 sp bfed9498 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:24 delpy kernel: hal-acl-tool: segfault at 8500000 ip
00a650c7 sp bf8bae78 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:24 delpy kernel: hal-acl-tool: segfault at 9c00000 ip
00a650c7 sp bfd3e2f8 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:33 delpy kernel: hal-acl-tool: segfault at 8f00000 ip
00a650c7 sp bffc6d78 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:33 delpy kernel: hal-acl-tool: segfault at 9600000 ip
00a650c7 sp bf966c18 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:36 delpy kernel: hal-acl-tool: segfault at 9300000 ip
00a650c7 sp bfca2a58 error 4 in libc-2.7.so[9f8000+153000]
Jul 9 00:52:36 delpy kernel: hal-acl-tool: segfault at 0 ip 00a650db sp
bfec5478 error 6 in libc-2.7.so[9f8000+153000]
Also it doesn't appear to include 10-usb-pda-palm.fdi file in the RPM, which was
removed from pilot-link because it was supposed to be included in this update:
$ rpm -ql hal-info
This means if I remove my manually created file:
/usr/share/hal/fdi/information/20thirdparty10-usb-pda-palm.fdi then pilot-link
-l -p usb: hangs.
OK, it looks like I made a mistake. I had not also installed the matching hal,
hal-libs as well (which is why it should have been included in the same update).
Now it appears to not crash.
I was also looking at the wrong file for pda, support it appears to have been
Seems like I'm affected by this now, too. hal, hal-info and a few other packages
were updated on my box this morning, and haldaemon service now fails to start.
That's too bad because sound stopped working, and kpowersave is unhappy, too.
And there's probably a lot of other applications that can't work w/o hal. I'm
*** [DIE] device_info.c:rules_match_and_merge_device():1089 : Rule is NULL on jump
when I run 'hald --daemon=no --verbose=yes'.
Downgrading to the previous hal-info version and starting the haldaemon service
makes things work again. Aargh.
Radek, does the patch in comment #4 fix it for you? (I don't get the crash in
the first place to try it).
Good news, Kevin. hal built locally with that patch added + the new hal-info work!
Yep, I had the same crash, the patch from comment #4 fixed it.
I just got a ton of "my network doesn't work" on Fujitsu lifebooks here, all of
which are traceable to the latest hal no longer starting. The root cause is
Falling back to the previous hal-info is what I'm currently doing
Orion: the fix is a patch that's already been committed upstream - could you add
the EasyFix keyword to the bug, please?
Comment #4 patch fixes for me too. Changing to hal. Let's get this fixed...
It's getting pretty ridiculous that this still hasn't been fixed in FC8 ... nearly two months after it was reported and at least six weeks after a valid and tested upstream fix has been identified.
For people suffering here are NMU binary packages with the fix applied:
And the SRPM whence they came:
Hopefully, at version 3.1 these are above the current RH version but below the next one they will release (hence equivalent to debian NMU packages) so you can apply them and still pull in the official fix if Red Hat gets around to releasing it.
Thanks James Bottomley, I've just backleveled and excluded hal* from update on all systems until a fix is released. I had almost forgotten about this issue.
*** Bug 454946 has been marked as a duplicate of this bug. ***
*** Bug 455577 has been marked as a duplicate of this bug. ***
David, could you apply this fix also to F8 version or is there anything that prevents that?
Same problem with the update that just went out:
It works with the updates from comment #14.
Yesterday (September the 13th) there was a new hal update, but it comes with the old problem and I needed to force the install of the old hal-info again.
I totally agree with the opening phrase of comment #14.
Since this has been open for nearly three months, with an easyfix (upstream patch) status, a high severity, and there has been no comment from the assigned maintainer, do we need to kick in the non-responsive/AWOL maintainer process? Is there some other issue that we need to be aware of in response to this problem, that precludes application of the upstream patch?
(In reply to comment #21)
> do we need to kick in the non-responsive/AWOL maintainer process?
It's clear that there has been, and is, active development of hal and associated projects/replacements; and that the Fedora packagers are intricately involved with the upstream projects.
But hal is now a key component of Fedora with wide-reaching effects, and it seems that there is often a delay getting getting fixes and updates out, particularly for existing releases (as opposed to rawhide).
It would probably be more constructive for the hal packager to add co-maintainers, or have a trusted triager/bugmaster (as Matěj Cepl does for the xorg packages). That, of course, needs someone to step up to the plate as a co-maintainer (as does the nuke option of the non-responsive maintainer process). Is that an offer? ;)
(I was personally frustrated by bug #280251 having a fix but being in kept in limbo for nigh on 6 months awaiting hal bugs; also bug #244995 with patch but unreleased for 12 months, bug #435093 with patch but unreleased for 4 months, bug #431377 open 7 months with patch for 2 months but still unfixed AFAIK. So I agree there is a bit of a problem here).
hal-0.5.10-5.fc8 has been submitted as an update for Fedora 8.
Confirming that this bug is corrected on my Toshiba laptop (the problem was not limited to Fujitsu machines) with hal-0.5.10-5.fc8 and hal-libs-0.5.10-5.fc8.
hal-0.5.10-5.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update hal'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-8433
hal-0.5.10-5.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.