Memleak with 0.0.20171221-5 on Debian stretch
baptiste at bitsofnetworks.org
Sun Feb 11 19:43:12 CET 2018
On 11-02-18, Daniel Kahn Gillmor wrote:
> Hi Baptiste--
> On Sun 2018-02-11 14:48:37 +0100, Baptiste Jonglez wrote:
> > On a x86_64 VM with quite a lot of Wireguard traffic (~300 GB per day), I
> > am seeing a memory leak with wireguard 0.0.20171221-5. System is Debian
> > stretch, kernel 4.9.65-3+deb9u2, wireguard package from unstable.
> oof, thanks for this report, and for the really useful graph
> it's troubling that the changes correlated with the memleak are both a
> kernel upgrade *and* a wireguard upgrade, since that kind of conflation
> might be difficult to tease apart.
Yes, I *think* it's related to wireguard and not the kernel upgrade (since
far more people use the kernel than wireguard), but I'm not 100% sure.
And indeed, we could imagine it to be an issue in wireguard related to the
> i'm curious from the graph -- do you know what happened at the start of
> week 6 where there's a sawtooth?
Actually, the amount of "slab_cache" didn't change at that point, it's
just the amount of application memory that dropped a bit. I looked at the
logs, some userspace processes were being killed by the OOM-killer.
> If you still see a leak with the latest wireguard, i'd appreciate if you
> could test the current kernel with 0.0.20171011-1 to see whether you can
> isolate the problem to the kernel. i'm not recommending running
> 0.0.20171011-1 for the long term, but it should still be wire-format
> compatible with other implementations and will help with debugging to
> have the comparison.
It does look like 0.0.20180202-1 still has the memleak. I will leave it
running a few more days to be certain, and then switch to 0.0.20171011-1.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the WireGuard