<div><div dir="auto">The original proxy design was like this:</div></div><div dir="auto"><br></div><div dir="auto">External TCP Source -> Proxy Process (binary transformation and analysis) -> External TCP Sink</div><div dir="auto"><br></div><div dir="auto">The current design added a new stage to the proxy by having 2 processes instead of 1:</div><div dir="auto"><br></div><div dir="auto">External TCP Source -> Proxy Process1 -> Proxy Process2 -> External TCP Sink</div><div dir="auto"><br></div><div dir="auto">Process1 forward the binaries (>64B) to Process2  which also inspects them (by logging suspicious packets).</div><div dir="auto"><br></div><div dir="auto">I will perform more checks today and report back.</div><div dir="auto"><br></div><div dir="auto"><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/31, Scott Ribe wrote:<br>
>> On Jan 31, 2019, at 3:26 PM, Frank Muller <<a href="mailto:frank.muller.erl@gmail.com" target="_blank">frank.muller.erl@gmail.com</a>> wrote:<br>
>><br>
>> The refc binary is the one using most of VM’s memory (in GB) compared to other allocators (few MB).<br>
><br>
>So, could be the classic leak where you match on a binary and pass a sub-binary to another process? That creates a ref to the original binary, and if the first process is a long-lived one that doesn't gc often, even though the second one finishes, the original binary hangs around...<br>
<br>
Yeah, that's a good bet. I'd check in the new feature where a sub-binary <br>
of a large binary is taken, and would call `NewBin = binary:copy(Bin)` <br>
on it to free the ref as early as possible.<br>
</blockquote></div></div>