memory leak

I am seeing this too. Seems to leak about 5 pages per minute:

21:41:36 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3125d000
21:41:36 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3125e000
21:41:36 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3125f000
21:41:36 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31260000
21:41:36 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31261000

...snip...

21:42:26 open("/proc/pmu/info", O_RDONLY|O_LARGEFILE) = 17
21:42:26 fstat64(17, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
21:42:26 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31262000
21:42:26 read(17, "PMU driver version : 2\nPMU f"..., 1024) = 109
21:42:26 read(17, "", 1024) = 0
21:42:26 close(17) = 0
21:42:26 munmap(0x31262000, 4096) = 0
21:42:26 munmap(0x31261000, 4096) = 0
21:42:26 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31261000
21:42:26 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31262000
21:42:26 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31263000
21:42:26 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31264000
21:42:26 poll([{fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=3, events=POLLIN}, {fd=11, events
=POLLIN}, {fd=12, events=0}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}, {fd=4, events=POLLIN}, {fd=10, events=POLLIN}, {fd=8, events=POLLIN, revents=POLLIN}], 13, 199
0) = 1
21:42:27 read(8, "B\1\0\1\0\0\0\27\0\0%D\0\0\0\325\1\1o\0\0\0\0M/org/fre"..., 2048) = 255
21:42:27 read(8, 0x1005c870, 2048) = -1 EAGAIN (Resource temporarily unavailable)
21:42:27 poll([{fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=3, events=POLLIN}, {fd=11, events
=POLLIN}, {fd=12, events=0}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}, {fd=4, events=POLLIN}, {fd=10, events=POLLIN}, {fd=8, events=POLLIN}], 13, 0) = 0
21:42:27 writev(8, [{"B\2\1\1\0\0\0\6\0\0\'*\0\0\0\37\6\1s\0\0\0\0\4:1.8\0\0"..., 48}, {"\0\0\0\1/\0", 6}], 2) = 54
21:42:27 poll([{fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=3, events=POLLIN}, {fd=11, events
=POLLIN}, {fd=12, events=0}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}, {fd=4, events=POLLIN}, {fd=10, events=POLLIN}, {fd=8, events=POLLIN}], 13, 1135) = 0
21:42:28 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x31265000
21:42:28 open("/proc/pmu/battery_0", O_RDONLY|O_LARGEFILE) = 17

I wonder if it is related to the read of /proc/pmu/info?

I was still seeing this leak in gutsy so I pulled the source, built debug packages and ran them under valgrind:

==7125== 3,776 bytes in 472 blocks are definitely lost in loss record 7 of 12
==7125== at 0xFFBAF40: malloc (vg_replace_malloc.c:149)
==7125== by 0xFE588F8: g_malloc (in /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0xFE723B4: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0xFE73A74: g_slist_prepend (in /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0x10012C88: hal_device_store_match_multiple_key_value_string (device_store.c:425)
==7125== by 0x10039184: pmu_poll (pmu.c:268)
==7125== by 0xFE50094: (within /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0xFE4F720: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0xFE539A4: (within /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0xFE53E10: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1400.1)
==7125== by 0x100140B8: main (hald.c:656)

So I created a patch to fix the leak and thought I would send a copy to the last person to touch the pmu.c file. To find this I looked at the hal git repo. Seems I was a bit late someone beat me to it:

http://gitweb.freedesktop.org/?p=hal.git;a=commitdiff;h=1491787fdf29fd77e4cbd13af70434ee3e7032ee

it looks like hal 0.5.10-5~ubuntu1 in hardy contains that patch

   * debian/patches/75_glist_memleak.patch
     - Added. Fixes some memleaks by not probably freeing GSList object (from
       upstream git)

Fixed in hardy. Thank you for your report!