How to fix libudev memory leaks? - c++

Question

I'm implementing a libudev based monitoring code for USB devices under the hidraw driver. I've implemented the standard example from the web and checked for memory leaks with valgrind and gdb.
/*******************************************
libudev example.
This example prints out properties of
each of the hidraw devices. It then
creates a monitor which will report when
hidraw devices are connected or removed
from the system.
This code is meant to be a teaching
resource. It can be used for anyone for
any reason, including embedding into
a commercial product.
The document describing this file, and
updated versions can be found at:
http://www.signal11.us/oss/udev/
Alan Ott
Signal 11 Software
2010-05-22 - Initial Revision
2010-05-27 - Monitoring initializaion
moved to before enumeration.
*******************************************/
I was unhappy to find that some libudev functions that are not supposed to allocate memory are leaking. I traced this by exiting (after all objects are unreff'ed) at differrent points and looking at the valgrind report. Specifically This code leaks:
int main (void)
{
struct udev *udev;
struct udev_enumerate *enumerate;
struct udev_list_entry *devices, *dev_list_entry;
struct udev_device *dev, *devParent;
struct udev_monitor *mon;
int fd;
/* Create the udev object */
udev = udev_new();
if (!udev)
{
printf("Can't create udev\n");
exit(1);
}
/* This section sets up a monitor which will report events when
blah blah....
"hidraw" devices. */
/* Set up a monitor to monitor hidraw devices */
mon = udev_monitor_new_from_netlink(udev, "udev");
udev_monitor_filter_add_match_subsystem_devtype(mon, "hidraw", NULL);
udev_monitor_enable_receiving(mon);
/* Get the file descriptor (fd) for the monitor.
This fd will get passed to select() */
fd = udev_monitor_get_fd(mon);
/* Create a list of the devices in the 'hidraw' subsystem. */
enumerate = udev_enumerate_new(udev);
udev_enumerate_add_match_subsystem(enumerate, "hidraw");
if (1)
{
// leak debug block
udev_enumerate_unref(enumerate);
udev_monitor_unref(mon);
udev_unref(udev);
return 0;
}
udev_enumerate_scan_devices(enumerate);
devices = udev_enumerate_get_list_entry(enumerate);
/* For each item enumerated, print out its information.
Here is the valgrind output:
==11424== HEAP SUMMARY:
==11424== in use at exit: 4,096 bytes in 1 blocks
==11424== total heap usage: 11 allocs, 10 frees, 28,086 bytes allocated
==11424==
==11424== LEAK SUMMARY:
==11424== definitely lost: 0 bytes in 0 blocks
==11424== indirectly lost: 0 bytes in 0 blocks
==11424== possibly lost: 0 bytes in 0 blocks
==11424== still reachable: 4,096 bytes in 1 blocks
==11424== suppressed: 0 bytes in 0 blocks
==11424== Rerun with --leak-check=full to see details of leaked memory
If I place the "leak debug block" one line prior to its above position valgrind exits with a clean result of 0 bytes leaked.
If I advance the block one line down the code the next function increases the leak size and components:
==14262== in use at exit: 8,192 bytes in 2 blocks
==14262== total heap usage: 45 allocs, 43 frees, 150,907 bytes allocated
==14262==
==14262== LEAK SUMMARY:
==14262== definitely lost: 0 bytes in 0 blocks
==14262== indirectly lost: 0 bytes in 0 blocks
==14262== possibly lost: 0 bytes in 0 blocks
==14262== still reachable: 8,192 bytes in 2 blocks
==14262== suppressed: 0 bytes in 0 blocks
==14262== Rerun with --leak-check=full to see details of leaked memory
It gets worse after the next line and it is of concern because my code needs to run over years and such leaks can accumulate unchecked.
Any suggestions why it happens and how to keep it under control?

Answer 1

Seems that these memory leaks related to the hash tables as reported by valgrind are not a concern see discussion in
https://github.com/libratbag/libratbag/issues/405 and a relevant Red Hat bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1280334.