hald memory leak

[mail@…]

When I leave my system running for a while, I see the memory usage of 'hald'
climbing. Currently from 'top':

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

1013 haldaemo 15 0 18680 16m 1372 S 0.0 13.0 0:02.52 hald

root@fic-gta01:~# uptime

21:06:40 up 15:55, 2 users, load average: 0.03, 0.03, 0.00

however in the past I have seen its virtual memory usage over 60MB.

Package version is: hal - 0.5.9-r5 - Hardware Abstraction Layer

My system is slightly non-standard - I have my root on the sd card, and for
several months I have updated it with 'ipkg upgrade' from my locally-built tree
(MokoMakefile?, monotone.openembedded.org, autorev) rather than doing a clean
re-install. I would appreciate it if someone with a 'clean' system could check
to see if they see the same hald behaviour after the system has been running for
a few days.

[reddog@…]

Also not a complete standard install, and maybe some days old:

dropbear invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
[<c002dbec>] (dump_stack+0x0/0x14) from [<c0073d78>] (oom_kill_process+0x58/0xec)
[<c0073d20>] (oom_kill_process+0x0/0xec) from [<c00742b4>]
(out_of_memory+0x1b8/0x218)

r7:000001c5 r6:c7d120c0 r5:c0363038 r4:c680d3e0

[<c00740fc>] (out_of_memory+0x0/0x218) from [<c00766ac>] (alloc_pages+0x26c/0x2f0)
[<c0076440>] (alloc_pages+0x0/0x2f0) from [<c00789c0>]
(do_page_cache_readahead+0x114/0x268)
[<c00788ac>] (do_page_cache_readahead+0x0/0x268) from [<c0078ff8>]
(do_page_cache_readahead+0x70/0x80)
[<c0078f88>] (do_page_cache_readahead+0x0/0x80) from [<c0073128>]
(filemap_fault+0x1d4/0x454)

r7:c767dac0 r6:c69a4000 r5:00000000 r4:00000000

[<c0072f54>] (filemap_fault+0x0/0x454) from [<c007eafc>] (do_fault+0x74/0x42c)
[<c007ea88>] (do_fault+0x0/0x42c) from [<c007fcb0>] (handle_mm_fault+0x304/0x728)
[<c007f9ac>] (handle_mm_fault+0x0/0x728) from [<c00300b4>]
(do_page_fault+0x100/0x23c)
[<c002ffb4>] (do_page_fault+0x0/0x23c) from [<c00302a4>]
(do_translation_fault+0x20/0x80)
[<c0030284>] (do_translation_fault+0x0/0x80) from [<c00281ec>]
(do_PrefetchAbort+0x18/0x1c)

r5:be88a9b8 r4:ffffffff

[<c00281d4>] (do_PrefetchAbort+0x0/0x1c) from [<c0028ec0>]
(ret_from_exception+0x0/0x10)
Exception stack(0xc69a5fb0 to 0xc69a5ff8)
5fa0: 00000000 be88a92c be88a8ac 00000000
5fc0: be88a9ac be88a9b8 00000000 be88a92c be88a8ac 00000001 00000004 00000001
5fe0: be88a92c be88a8a0 00010434 00010434 00000010 ffffffff
Mem-info:
DMA per-cpu:
CPU 0: Hot: hi: 42, btch: 7 usd: 38 Cold: hi: 14, btch: 3 usd: 13
Active:28622 inactive:148 dirty:0 writeback:0 unstable:0

free:404 slab:1086 mapped:0 pagetables:151 bounce:0

DMA free:1616kB min:1440kB low:1800kB high:2160kB active:114488kB inactive:592kB
present:130048kB pages_scanned:211264 all_unreclaimable? yes
lowmem_reserve[]: 0 0 0
DMA: 30*4kB 7*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB
0*4096kB = 1616kB
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap = 0kB
Total swap = 0kB
Free swap: 0kB
32768 pages of RAM
585 free pages
1631 reserved pages
1086 slab pages
123 pages shared
0 pages swap cached
Out of memory: kill process 1093 (hald) score 453 or a child
Killed process 1094 (hald-runner)

[sillern]

I have a clean 2008.8 image, with some opkg update/upgrade from zeckes stuff, and I'm experiencing this issue.

hald is occupying 48.1% of the memory according to "top".

What can I do to debug this issue and give more info?

[zecke]

Use something like exmap to take a look at the memory usage. Maybe even break in malloc and see what it is doing.

Assumption: Due the LED triggers we can fire a lot of uevents and parse the battery data a lot. I would start looking there... or even patch the kernel to change battery signal changed bits...

Also look which version of hald we have and then take a look at the changelog to see if a leak was fixed upstream.

[zecke]

I just git-cloned hal and there are a couple of leak fixes done in 2008. We should attempt a hald upgrade.

[zecke]

​http://bugs.freedesktop.org/show_bug.cgi?id=16376

[zecke]

And the result of search for leak in git-log since the release of 0.5.9

3c88150d1f908c5a3de2cd9946916907471ea7d9
d2572a16cd5e6a5e5bab066595f43125ccdeb64a
1168f61e5ab9edc5db9beb85aa91e8bd2edc3b7f
5d4605190053c89af40c76ea84f2f11ea4fcd14e
581d3dadff6555ea96255fd328f2427ddc1f93b2
08aec20d691b180541b07eab8382999c1b08141e
5c2e2c152c4ddbc63d72740f3957e74f735af6b3
b9788b894ecb7728293aadd1840cc424d056be86
b8f72cec53415ebc2d32805b049dcc94cef4a854
02d471d199d6a50f989cde9f452f5f70dc9f7a3d
1491787fdf29fd77e4cbd13af70434ee3e7032ee
96834a07de4fe66d506427a99b001f796ddea019
314ee3c92e02b35c19a14e0d7465e7c0df2a7903

string handling in C is... :)

[zecke]

Okay, I have put hald 0.5.11 into org.openmoko.asu.dev and org.openmoko.asu.testing. connmand is still able to find our network device, no other regression testing was done.

[graeme]

These changes are in OM.dev branch now!

[zecke]

Consider that as resolved.