Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 57184
Status: resolved
Priority: 0/
Queue: CGI

Owner: Nobody in particular
Requestors: jgoodridge [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

From jgoodridge [...] Mon May 3 17: 11:25 2010
MIME-Version: 1.0
X-Spam-Status: No, score=-8.159 tagged_above=-99.9 required=10 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8, SPF_NEUTRAL=0.686] autolearn=ham
X-Spam-Flag: NO
X-Virus-Checked: Checked by ClamAV on
Content-Type: multipart/alternative; boundary=0016367b657049f8ee0485b70983
Message-ID: <s2n5d395bd51005031411w51a43290l82fbec5cca3994f2 [...]>
Reply-To: jgoodridge [...]
X-Virus-Scanned: Debian amavisd-new at
X-Spam-Score: -8.159
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E2CF240292 for < [...]>; Mon, 3 May 2010 17:11:25 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vn+6qpXUFoja for < [...]>; Mon, 3 May 2010 17:11:22 -0400 (EDT)
Received: from ( []) by (Postfix) with SMTP id 7E444240088 for < [...]>; Mon, 3 May 2010 17:11:22 -0400 (EDT)
Received: (qmail 31141 invoked by uid 103); 3 May 2010 21:11:36 -0000
Received: from ( by with QMQP; 3 May 2010 21:11:36 -0000
Received: from (HELO ( by (qpsmtpd/0.80) with ESMTP; Mon, 03 May 2010 14:11:31 -0700
Received: by wwb39 with SMTP id 39so65312wwb.9 for < [...]>; Mon, 03 May 2010 14:11:28 -0700 (PDT)
Received: by with SMTP id t20mr4115890wek.163.1272921088194; Mon, 03 May 2010 14:11:28 -0700 (PDT)
Received: by with HTTP; Mon, 3 May 2010 14:11:28 -0700 (PDT)
Authentication-Results: (amavisd-new); dkim=pass header.i= [...]
Authentication-Results: (amavisd-new); domainkeys=pass header.from=jgoodridge [...]
Delivered-To: [...]
Subject: Bug found and fixed
Return-Path: <jgoodridge [...]>
Domainkey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=fHaFlqhO6gZTl2ZqQ0g8srfg1txYePNTM4kFZDJrKyfi5MclQH+CQ/I5doWw9ABbl6 WBf9OaGozI81Z57zBbS4gNKgaEearA2+4tMqZNjGlBjL7m7QWXeucgiPWRDhnybSE3RX beQdSxo7v3XQbu9w20PCuP6Q9EHDrRZSLCJZM=
X-Original-To: [...]
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=4aY+19Jlfyo3pT+EDDl2Bzp2+yN1gMhrVkwCEQUX2UA=; b=LQSNC/6k91gHFvIHl7Du9Zyeb7L57pNyJXqOacR0NRZvHeZMeNKaoQ5Vy0iJ42s0hr zCc8L87khfOyFDbEAdIw7OoU/SPSTJ6L1XEk9ufjpuBZR6ruEnfeBXj+UqqySjQic8xq U9R7XUoUwYMWBtALKz46PVc711tbSEHGugG+Y=
Date: Mon, 3 May 2010 14:11:28 -0700
To: [...]
From: Jeremy Goodridge <jgoodridge [...]>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: ISO-8859-1
Content-Length: 2234
Download (untitled) / with headers
text/plain 2.1k
I have found a problem in in which CGI params do not get refreshed on subsequent requests. This didn't happen with every request, but I found that after about 5 minutes or 30 requests or so, suddenly, CGI would start using the same parameters for every request. The problem occurred on mod_perl 1.31 but NOT on mod_perl 1.29. I don't know about mod_perl 1.30. To fix I changed line 360: from: $r->register_cleanup(\&CGI::_reset_globals); to: $r->push_handlers( 'PerlCleanupHandler', \&CGI::_reset_globals); I thought the two snippets of code were identical but apparently not. So, this may really expose a mod_perl problem, or perhaps register_cleanup is now deprecated. Note that adding the cleanup handler explicitly in the httpd conf also works. So, specifically, adding PerlCleanupHandler CGI::_reset_globals to one's httpd conf fixes the problem. I believe this problem is related to the following conversation I found: This conversation mentioned an incompatibility between Apache::SizeLimit and I AM using Apache::SizeLimit and so that might be what exposes the problem. That might be why it takes some time to occur -- perhaps once Apache SizeLimit is engaged, CGI's cleanup handler is destroyed. I don't know. Or perhaps it is something fundamental within mod_perl. My installation includes: Apache: 1.3.41 mod_perl: 1.31 3.49 Apache::SizeLimit 0.91-dev Redhat EL5. As a further note, I noticed the following in the source code: # This used to use $r->post_connection but there's no good way to # test it, since apparently it does not push a handler onto the # PerlCleanupHandler phase. That means that there's no way to use # $r->get_handlers() to check the results of calling this method. $r->push_handlers( 'PerlCleanupHandler', sub { $class->_exit_if_too_big(shift) } ); So, that suggests to me that post_connection (which is supposed to be identical to register_cleanup) doesn't quite do what is expected. And reinforces the need for my fix. Please let me know if you have questions or need more information about my setup. Jeremy Goodridge
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
X-RT-Original-Encoding: ISO-8859-1
Content-Length: 3706
MIME-Version: 1.0
In-Reply-To: <s2n5d395bd51005031411w51a43290l82fbec5cca3994f2 [...]>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <s2n5d395bd51005031411w51a43290l82fbec5cca3994f2 [...]>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-21313-1358649236-219.57184-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 468
Download (untitled) / with headers
text/plain 468b
I'm hesitant to make the proposed change based on feedback from just one person, with no else adding a even one more "me too" comment in the past 3 years. It's a further concern that the issue is not reproducible with a automated test. To be conservative on changes to this widely used module, I'm marking this as "resolved" due to old age. It can be re-opened if we get a second data point. I've given the ticket a clearer subject to make it easier to find.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to