New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak #229

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

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 added a commit that referenced this issue Sep 29, 2016

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.
@pierky

This comment has been minimized.

Show comment
Hide comment
@pierky

pierky Oct 3, 2016

Contributor

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.

Contributor

pierky commented Oct 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Oct 3, 2016

Member

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

Wow, what an embarrassing mistake.

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

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Oct 3, 2016

Member

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

Member

ydahhrk commented Oct 3, 2016

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

ydahhrk referenced this issue Oct 3, 2016

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.
@ydahhrk

This comment has been minimized.

Show comment
Hide comment
@ydahhrk

ydahhrk Oct 3, 2016

Member

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

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