Memory leak #229

Closed
ydahhrk opened this Issue Sep 29, 2016 · 4 comments

Projects

None yet

2 participants

@ydahhrk
Member
ydahhrk commented Sep 29, 2016

Jool 3.5.0. NAT64 only. Reserved memory grew from 709 to 1655 megabytes in 10 days. The leak doesn't seem that fast but might be exploitable.

/proc/slabinfo suggests the objects being leaked are larger than 96 bytes and smaller or equal than 128.

@ydahhrk ydahhrk added this to the 3.5.1 milestone Sep 29, 2016
@ydahhrk ydahhrk added a commit that referenced this issue Sep 29, 2016
@ydahhrk ydahhrk Improve object "tracker"
Was only keeping track of kmallocs; was ignoring kmem caches.
It seems that #229 is a kmem cache leak so I had to improve the
wkmalloc module.
e10e610
@pierky
Contributor
pierky commented Oct 3, 2016 edited

I could easily reproduce this bug on 3.5.0 by pushing 1 Gbps through Jool: kmalloc-128 and free's buff/cache raised quickly. Then I wanted to have a glimpse of this commit: they are still raising but far more slowly than before. I enabled the kmemleak and gathered some info: I send a file containing the report to jool@nic.mx - I hope it can help you.

@ydahhrk
Member
ydahhrk commented Oct 3, 2016

Thanks! Will keep this tool handy for next time; this output led me to the problem right away.

Wow, what an embarrassing mistake.

@ydahhrk
Member
ydahhrk commented Oct 3, 2016 edited

Flood pinging. It still seems to be leaking something, but at a much slower rate.

@ydahhrk ydahhrk referenced this issue Oct 3, 2016
@ydahhrk ydahhrk Patch memory leak during v4 UDP/ICMP packet handling.
A session was leaking during the translation of every such packet.

Also added a bunch of mess to monitor memory leaks when we want to
test them.
dc40eeb
@ydahhrk
Member
ydahhrk commented Oct 3, 2016

Ok, I don't see any more leaks. Will monitor it for two more days and then release 3.5.1.

@ydahhrk ydahhrk closed this in 53b1f15 Oct 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment