On Thu, May 08, 2014 at 05:28:54PM +0200, Thomas Gleixner wrote:
> > > All I see in dmesg are occasional ooms which kill random trinity
> > > childs.
> >
> > hm, that sounds odd. if it's only fuzzing futex, it shouldn't be
> > doing much memory allocation.
>
> It has a fast memory leak of some sort.
>
> 9271 tglx 20 0 198908 75320 2992 S 0.7 7.4 0:01.94 trinity-c0
> 9271 tglx 20 0 256888 104368 2992 S 3.3 10.2 0:02.78 trinity-c0
ah, it's probably where it generates a random address.
See random-address.c:get_writable_address. This is hitting the 'zmalloc' case.
For the most time, leaking this isn't a big deal, as the child usually
crashes in some way before it becomes a problem. But when we narrow the
possible syscalls it can run as we have in this case, it runs and runs..
until oom.
You could either chop out that case of the switch, or do something like
this..
while [ 1 ];
do
./trinity -c futex -l off -q -n 1000000
done
Which forces it to quit and restart every million syscalls.
Kinda hacky, but I've not had motivation to get around to fixing this
(and similar) leaks so far because I keep finding more interesting
things to work on..
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
