Bug 1274632 - Sometimes hald lost removing notification of device due to leak of needless device information.
Sometimes hald lost removing notification of device due to leak of needless d...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: hal (Show other bugs)
All Linux
unspecified Severity low
: rc
: ---
Assigned To: Richard Hughes
Desktop QE
Depends On:
  Show dependency treegraph
Reported: 2015-10-23 04:06 EDT by Yuki Shibuya
Modified: 2017-12-06 05:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-06 05:55:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Yuki Shibuya 2015-10-23 04:06:30 EDT
Description of problem:
When we repeat connect and disconnect of devices, sometimes removing notification of device is lost. Therefore if our application use libhal to get dbus notification from hald, our application can't get removing notification from dbus. I found that the reason of this problem is leak of needless device information.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
This problem was occurred in other distribution using hal-0.5.13. In RHEL 6, I found following patch in hal-0.5.14-14.el6.src.rpm.


I think that lost removing notification of device is fixed by above patch. However I think that leak of needless device information exist yet.

Actual results:

hald doesn't lost removing notification of device with leak of needless device information.

Expected results:

hald doesn't lost removing notification of device without leak of needless device information.

Additional info:

If hal catches a removing event of device from udev, it search device data from hash table by
using sysfs.path. In removing process, hal does not delete this device data from
hash table. The key of hash table is pointer of device sysfs.path, and this pointer is freed in
removing process. However, sometimes data of pointer address is not cleared immediately.
When same device is connected to machine again, device data is registered with previous freed address 
to hash table. In this case, if this address is reused, hal can't find device data of same device 
in removing process.


In above patch, the key of hash table is not address depended on device structure because
it is result of g_strdup of original address. However, the entry of device in hash tables is not
removed in removing process. I think that is leak of needless device.

In hal-0.5.13, I applied following patch and confirmed that this problem is fixed. In this patch, 
the entry that value is an empty list is removed in removing process.
I think this operation is need to hal-0.5.14 to avoid leak of needless device.

diff -ur a/hald/device_store.c b/hald/device_store.c
--- a/hald/device_store.c       2008-08-10 22:50:10.000000000 +0900
+++ b/hald/device_store.c       2015-10-23 10:03:23.027666861 +0900
@@ -519,7 +519,11 @@
                HAL_DEBUG (("removing %p from (%s,%s)", device, key, value));
                devices = g_slist_remove_all (devices, device);
-       g_hash_table_insert (index, (gpointer) value, devices);
+       if (g_slist_length (devices)) {
+               g_hash_table_insert (index, (gpointer) value, devices);
+       } else {
+               g_hash_table_remove (index, value);
+       }

 #if GLIB_CHECK_VERSION (2,14,0)
Comment 2 Jan Kurik 2017-12-06 05:55:56 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:


This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:


Note You need to log in before you can comment on or make changes to this bug.