E
Eric Wong
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:
Yes, I suck at reading and can't write code properly as a result.
* http://unicorn.bogomips.org/
* (e-mail address removed)
* git://git.bogomips.org/unicorn.git
(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
collector.
Yes, I suck at reading and can't write code properly as a result.
* http://unicorn.bogomips.org/
* (e-mail address removed)
* git://git.bogomips.org/unicorn.git