On Sun, 25 Nov 2007 20:16:00 -0500
Sam Carleton [EMAIL PROTECTED] wrote:
Thanks to the performance tools of my OS I have confirmed that
somewhere in my Apache module there is a memory leak. Are there any
tips or tricks out there for find memory leaks in an Apache module?
Run inside gdb as a
On Sun, 25 Nov 2007 21:32:13 -0500
Sam Carleton [EMAIL PROTECTED] wrote:
With this memory leak in my simple Apache module, I am considering
rewriting the whole module. Right now there are two files small files
that the module reads every time. One is a small (less then a 1K)
configuration
Am Sonntag, den 25.11.2007, 21:32 -0500 schrieb Sam Carleton:
In
the rewrite, I am considering caching the data in these files and
reading them only if they are changed. The question though is:
Considering how small these files are, will the performance gains be
worth the extra development
On 11/26/07, ed [EMAIL PROTECTED] wrote:
Generally speaking, if you're using apr routines then they should
handle the memory resources for you, there should be little need for
allocating on the heap.
mod_include has an expression parser (parse_expr at line 1125
in /trunk/). Many other modules implement simpler parsers for
a range of purposes.
It seems to me we could potentially benefit from a general-
purpose expression parser, and I'm wondering about extracting
mod_include's parse_expr as
On Mon, November 26, 2007 4:18 pm, Nick Kew wrote:
mod_include has an expression parser (parse_expr at line 1125
in /trunk/). Many other modules implement simpler parsers for
a range of purposes.
It seems to me we could potentially benefit from a general-
purpose expression parser, and I'm
On Nov 17, 2007 9:36 AM, [EMAIL PROTECTED] wrote:
Author: niq
Date: Sat Nov 17 06:36:58 2007
New Revision: 595954
URL: http://svn.apache.org/viewvc?rev=595954view=rev
Log:
Safer fix to PR43882 than in r595672.
Modified:
httpd/httpd/trunk/modules/http/http_filters.c
Modified:
On Mon, 26 Nov 2007 10:38:28 -0500
Jeff Trawick [EMAIL PROTECTED] wrote:
What is the intention for the UNHANDLED case?The code/comments
seem to imply we'll end up in the respect CL path.
Exactly.
The alternative is to reject it, which might risk breaking
something that worked before. The
Hi All,
I accidentally committed an upgrade to httpd/httpd/vendor/pcre/current
to 7.4. I apparently had a commit bit there because I'm on the PMC from
past apreq work.
I immediately asked what to do over on #infra on freenode and jerenkrantz
agreed I should back it out so I did.
It was
On Nov 26, 2007 11:50 AM, Nick Kew [EMAIL PROTECTED] wrote:
On Mon, 26 Nov 2007 10:38:28 -0500
Jeff Trawick [EMAIL PROTECTED] wrote:
What is the intention for the UNHANDLED case?The code/comments
seem to imply we'll end up in the respect CL path.
Exactly.
Cool; we're in sync so far,
I figured after the earlier snafu, I should at least send this to the list
for review. I won't do anything with it unless people think its a good
thing.
--
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Senior
On 11/26/2007 03:56 PM, [EMAIL PROTECTED] wrote:
Author: niq
Date: Mon Nov 26 06:56:12 2007
New Revision: 598299
URL: http://svn.apache.org/viewvc?rev=598299view=rev
Log:
mod_filter: don't segfault on (unsupported) chained FilterProviders.
PR 43956
Modified:
On Mon, 26 Nov 2007, Philip M. Gollucci wrote:
I figured after the earlier snafu, I should at least send this to the list
for review. I won't do anything with it unless people think its a good
thing.
Aslo, I mean to add:
Affected package: pcre-7.2
Type of problem: pcre -- arbitrary code
On Nov 26, 2007, at 6:59 AM, Philip M. Gollucci wrote:
I accidentally committed an upgrade to httpd/httpd/vendor/pcre/current
to 7.4. I apparently had a commit bit there because I'm on the PMC
from past apreq work.
I immediately asked what to do over on #infra on freenode and
jerenkrantz
On Nov 26, 2007 4:28 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
Generally speaking, if someone tells you to do something in IRC
then it is almost certainly the wrong thing to do -- just like
decisions made in boring meetings.
Philip said he never intended to commit it.
The right thing to
Justin Erenkrantz wrote:
Once we switched our code to supporting external PCREs, in my opinion,
we should have just dropped the whole vendor branch concept as it
serves no legitimate purpose any more. If the PCRE guys are doing
releases now (it seems someone is home now), then we should just
On Nov 26, 2007 8:01 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Justin Erenkrantz wrote:
Once we switched our code to supporting external PCREs, in my opinion,
we should have just dropped the whole vendor branch concept as it
serves no legitimate purpose any more. If the PCRE guys
On Nov 26, 2007, at 8:20 PM, Justin Erenkrantz wrote:
On Nov 26, 2007 8:01 PM, William A. Rowe, Jr. [EMAIL PROTECTED]
wrote:
Justin Erenkrantz wrote:
Once we switched our code to supporting external PCREs, in my
opinion,
we should have just dropped the whole vendor branch concept as it
On Nov 26, 2007 8:46 PM, Roy T. Fielding [EMAIL PROTECTED] wrote:
Okay with me. All we need now is a volunteer to figure out what
(if any) changes are needed to use a separately installed PCRE.
All hail Guido's time machine than has been hijacked by Joe. =) -- justin
% ./configure --help |
19 matches
Mail list logo
