[#3113] Problem in RSS library, or problem in my blog :) — Dave Thomas <dave@...>
I've been trying to use the new RSS library to parse a number of
7 messages
2004/07/01
[#3136] Wrong rdoc formatting in {array,pack}.c — Johan Holmberg <holmberg@...>
7 messages
2004/07/05
[#3162] Re: [doc-patch] Wrong rdoc formatting in {array,pack}.c
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/07/09
Hello.
[#3170] Another rdoc formatting error in array.c
— Johan Holmberg <holmberg@...>
2004/07/10
[#3172] Re: [doc-patch] Another rdoc formatting error in array.c
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2004/07/12
Hello.
[#3141] rexml/validation/validationexception is missing. — nobu.nokada@...
Hi,
5 messages
2004/07/06
[#3154] Nonblocking socket connect - Win32 - 181 — "Jean-Francois Nadeau" <jean-francois.nadeau@...>
Hi,
4 messages
2004/07/08
[#3167] Inconsistent "call-seq" usage etc. — Johan Holmberg <holmberg@...>
7 messages
2004/07/09
[#3168] Re: [doc] Inconsistent "call-seq" usage etc.
— Dave Thomas <dave@...>
2004/07/09
[#3171] binding a URL to a label in RDoc — Ian Macdonald <ian@...>
Hello,
6 messages
2004/07/12
[#3199] Trying to understand \G — Dave Thomas <dave@...>
I'm being silly again, but I can't get \G to work with String.index. If
12 messages
2004/07/16
[#3213] Typo and grammar/style fixes for ext/win32ole/win32ole.c — Jos Backus <jos@...>
The attached patch attempts to create a more consistent style for error
4 messages
2004/07/19
[#3216] Re: Incident Analysis of the intrusion on helium.ruby-lang.org May 2004 — "Sean E. Russell" <ser@...>
Hi,
6 messages
2004/07/21
[#3228] Core support for Gems, and namespace — "Luke A. Kanies" <luke@...>
Hi all,
21 messages
2004/07/27
[#3229] Re: Core support for Gems, and namespace
— Dave Thomas <dave@...>
2004/07/27
[#3232] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Tue, 27 Jul 2004, Dave Thomas wrote:
[#3233] Re: Core support for Gems, and namespace
— Gavin Sinclair <gsinclair@...>
2004/07/27
On Wednesday, July 28, 2004, 12:48:07 AM, Luke wrote:
[#3235] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Wed, 28 Jul 2004, Gavin Sinclair wrote:
[#3230] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/27
On Tue, 27 Jul 2004 11:39:08 +0900, Luke A. Kanies <luke@madstop.com> wrote:
[#3234] Re: Core support for Gems, and namespace
— "Luke A. Kanies" <luke@...>
2004/07/27
On Tue, 27 Jul 2004, Austin Ziegler wrote:
[#3238] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/27
On Wed, 28 Jul 2004 00:14:29 +0900, Luke A. Kanies <luke@madstop.com> wrote:
[#3243] Re: Core support for Gems, and namespace
— Gavin Sinclair <gsinclair@...>
2004/07/28
On Wednesday, July 28, 2004, 3:23:46 AM, Austin wrote:
[#3248] Re: Core support for Gems, and namespace
— Austin Ziegler <halostatue@...>
2004/07/28
On Wed, 28 Jul 2004 11:29:53 +0900, Gavin Sinclair
[#3249] Re: Core support for Gems, and namespace
— Mauricio Fern疣dez <batsman.geo@...>
2004/07/28
On Wed, Jul 28, 2004 at 11:29:53AM +0900, Gavin Sinclair wrote:
cgi.rb possible memory leak
From:
Kent Sibilev <ksibilev@...>
Date:
2004-07-28 07:05:07 UTC
List:
ruby-core #3245
Hi all.
We are almost ready to deploy our commercial website completely written
in Ruby and we are finishing up our testings. Our application is
running in FastCGI environment using ruby-fcgi-0.8.4 binding.
Recently I've noticed that the memory usage of our Ruby processes goes
very high after intensive usage and never goes down. I wrote a simple
memory monitoring tool which uses ObjectSpace module to display the
current heap content. I noticed that there were a lot of StringIO and
Tempfile object hanging around and never got released by garbage
collector. The only place where these objects can be created is inside
the CGI class when the HTTP POST request has a multipart form. Having
spent a couple of hours in debugger, I was able to identify the source
of the problem. All these objects were marked by rb_mark_end_proc(),
which was very alarming especially that 'end_procs' list was unusually
huge.
The reason of all this was the following code snippet in cgi.rb
initialize method:
2268: initialize_query() # set @params, @cookies
2269: params = @params.nil? ? nil : @params.dup
2270: cookies = @cookies.nil? ? nil : @cookies.dup
2271: (class << self; self; end).class_eval do
2272: const_set(:CGI_PARAMS, params)
2273: const_set(:CGI_COOKIES, cookies)
2274: end
2275: if defined?(MOD_RUBY) and (RUBY_VERSION < "1.4.3")
2276: raise "Please, use ruby1.4.3 or later."
2277: else
2278: at_exit() do
2279: if defined?(CGI_PARAMS)
2280: CGI.class_eval do
2281: remove_const(:CGI_PARAMS)
2282: remove_const(:CGI_COOKIES)
2283: end
2284: end
2285: end
2286: end
If you look at it CGI class parses form query parameters and at the end
calls at_exit function. As it turned out the block passed to at_exit
function gets registered into Ruby's end_procs list and this block
holds the references to all parsed query parameters. Ruby interpreter
on the other hand cleans up this end_procs list only on the process
exit. This means that all this parsed query parameters including in my
case Tempfiles and StringIOs are sitting in memory doing nothing. And
it happens for every HTTP request! Commenting out the at_exit call made
the process memory bound to ~30M.
I don't know what was the reason to put this at_exit hook in there.
Probably whoever wrote it (many thanks, BTW) assumed that CGI module
will be used in the strictly CGI environment where process dies at the
end of the request processing. But it is a real problem in the FastCGI
environment!
BTW, I think I've found another small memory leak in ruby-fcgi-0.8.4
extension library. Can somebody verify that? Here is the diff:
@@ -37,6 +37,12 @@
rb_gc_mark(data->env);
}
+static void fcgi_free(fcgi_data *data)
+{
+ xfree(data->req);
+ xfree(data);
+}
+
static VALUE fcgi_s_accept(VALUE self)
{
int status;
@@ -64,7 +70,7 @@
VALUE obj,key, value;
char *pkey,*pvalue;
- obj = Data_Make_Struct(self, fcgi_data, fcgi_mark, 0, data);
+ obj = Data_Make_Struct(self, fcgi_data, fcgi_mark, fcgi_free,
data);
data->req = req;
data->in = Data_Wrap_Struct(cFCGIStream, 0, 0, req->in);
data->out = Data_Wrap_Struct(cFCGIStream, 0, 0, req->out);
Thanks for listening.
Cheers,
Kent.