[erlang-questions] Port handlers and binary leaks?

Robert Raschke <>
Mon Oct 17 18:12:03 CEST 2016


I find the easiest way to think about (large) binaries is through
remembering that they are shared "objects". Any process that has a
"pointer" into a binary like that, means the binary as a whole needs to
stick around. Pattern matching on binaries creates such pointers.

A common problem arises when you have one process creating such a binary,
then taking it apart using pattern matching, and passing those "parts" on
for further processing. All those parts now refer back to the original
large binary, which therefore cannot get collected.

In order to work around this "optimisation",  the common approach is for
the process taking apart the binary to make copies of the parts to pass
along for further processing. Thus references into the original binary are
avoided and it can get collected.

Cheers,
Robby
On 17 Oct 2016 13:26, "Oliver Korpilla" <> wrote:

> Hello.
>
> Recent reading got me concerned about leaking memory by having big refc
> binaries.
>
> In our system we have permanent TCP and SCTP handlers that receive outside
> messages, then forward it into the system for processing.
>
> For example, these events have ASN.1 payloads. Decoding is done in
> throw-away processes... however, I'm concerned that the TCP and SCTP
> handling processes might cause memory leaks because every payload buffer is
> handled there first.
>
> I saw in "Erlang in Anger" that routers should only return where to route
> to, not handle the message. But when handling sockets I don't see that
> option?
>
> What is good practice here? Am "I" at risk?
>
> Thanks and best regards,
> Oliver
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161017/77c8018a/attachment.html>


More information about the erlang-questions mailing list