Mojo::IOLoop::Stream memory hog

[leonerd]

• Mojolicious version: 7.29
• Perl version: 5.14.2 threaded
• Operating system: Debian Linux x86

Steps to reproduce the behavior

The {buffer} field of a Mojo::IOLoop::Stream stores pending bytes for output. Once written, they are substr()ed out of the buffer. This means that the memory usage of the actual buffer SV is never actually returned to the malloc pool.

This has the problem that if e.g. a temporary network stall happens, large buffers are created that use up lots of memory, which perl never gets around to reusing even after the buffers are flushed.

Expected behavior

Once the underlying _write method has successfully flushed the contents of the buffer, it should be undefed to return the actual byte buffer back to the malloc pool, so it can be reused.

Actual behavior

Because currently it doesn't get undefed, any allocated byte storage remains, consuming memory that the rest of the process can't use.

[leonerd]

It is important to actually undef the buffer - merely assigning "" into it won't suffice:

eval: my $buffer = "A"x1E6; $buffer = ""; Dump $buffer
SV = PV(0x564e1a222bf0) at 0x564e1a24eef8
  REFCNT = 2
  FLAGS = (POK,pPOK)
  PV = 0x7fb180c50010 ""\0
  CUR = 0
  LEN = 1000002

Here, the buffer itself is still using a million bytes of RAM (the LEN field)

eval: my $buffer = "A"x1E6; undef $buffer; $buffer = ""; Dump $buffer
SV = PV(0x564e1a222bf0) at 0x564e1a24eef8
  REFCNT = 2
  FLAGS = (POK,IsCOW,pPOK)
  PV = 0x564e1a25ebb0 ""\0
  CUR = 0
  LEN = 10
  COW_REFCNT = 1

The old buffer has been returned to the malloc pool, and a new one created at only 10 bytes long.

[jberger]

So we've added this change to hopefully address the problem. We haven't come to a good way to test it in the test suite, so for a first check @leonerd can you see if this at least is effective?

[leonerd]

Yeah, testing this kind of thing is always rather tricky. But the code looks to be doing the right thing on a visual inspection at least.

I can deploy it and see how it behaves, though due to the rare nature of the problem in practice it may be a while before it turns up again.

[jberger]

In that case I think I'll close this for now and please feel free to either reopen or open a new bug and reference this one if you should notice it in the future.

Thanks again for the report.