First off, this memory leak doesn’t affect Unicorn itself at all
(but it doesn’t hurt, either).
Unicorn itself always allocates the HttpParser once and always reuses it
in every sequential request.
This leak only affects applications that repeatedly allocate a new HTTP
parser. Thus this bug affects all deployments of Rainbows! and
Zbatery. These servers allocate a new parser for every client
connection to serve clients concurrently, but due to a bug in Unicorn,
never allows the Ruby GC to properly free the memory allocated.
Here’s what happened:
I misread the Data_Make_Struct()/Data_Wrap_Struct()
documentation and ended up passing NULL as the “free” argument
instead of -1, causing the memory to never be freed.
From README.EXT in the MRI source which I misread:
The free argument is the function to free the pointer
allocation. If this is -1, the pointer will be just freed.
The functions mark and free will be called from garbage
Yes, I suck at reading and can’t write code properly as a result.
This release depends on Unicorn 0.96.1 for an updated
Unicorn::HttpParser to avoid leaking memory.
The HttpParser in Unicorn <= 0.96.0 did not setup the parser
object properly to be freed by the garbage collector.
While this bug did not affect Unicorn itself, Rainbows!
allocates a new Unicorn::HttpParser object for every new client
connection and Unicorn did not properly setup the parser object
to be freed by the Ruby garbage collector.
There are also minor cosmetic cleanups and fixes:
Eric W. (10):
http_response: disallow blank, multi-value headers
Fix “rainbows -h” and “rainbows -v”
Update docs + tests to reflect Rev 0.3.2 release
local.mk.sample: bump Rack dependency
Merge branch ‘rack-1.1’
add Cramp integration tests
Rakefile: autoload Gem
t/bin/*: encoding should be the first line after shebang
gemspec: bump dependency on Unicorn to avoid leak
Almost forgot about this one, I have a short attention span and no ability to comprehend what I read!
This fixes a misuse of the Ruby API leading to memory leaks in
cases where message queues are continually opened and closed
throughout the lifetime of the application.
Fortunately applications have little reason to repeatedly open
and close message queue descriptors: they are
multi-thread/multi-process-safe in every way imaginable and also
capable of non-blocking operation.
POSIX message queues allow local processes to exchange data in the form
of messages. This API is distinct from that provided by System V
message queues, but provides similar functionality.