Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 37100]  -
    SEGV in mod_proxy_ajp
Message-Id: <20051019213456.D57F1237@ajax.apache.org>
Date: Wed, 19 Oct 2005 23:34:56 +0200 (CEST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37100>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37100


------- Additional Comments From rpluem@apache.org  2005-10-19 23:34 -------
(In reply to comment #13)
> (In reply to comment #4)
> > Created an attachment (id=16722)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16722&action=view) [edit] [edit]
> > Patch against trunk
> 
> I tried this one, and it's buggy.  You need to have a line like:
>    conn->data = NULL;
> somewhere around the brigade cleanups, or after a couple of requests you'll 
> SEGV because conn->data->buffer isn't valid anymore.

Sorry, but you are confusing me. I guess you mean ((ajp_msg_t *)conn->data)->buf
instead of conn->data->buffer. ((ajp_msg_t *)conn->data)->buf gets allocated out
of the request pool. This pool and thus the buffer remain valid for the livetime
of the request. In line 212 conn->data is set to NULL. As we only use
((ajp_msg_t *)conn->data)->buf during the lifetime of the request it does not
get invalid. If we would set conn->data to NULL after the brigade cleanup in
line 326 we would reintroduce the memory leak as we would allocate more memory
out of the request pool which gets only cleared after the request has been
finished. So if you still see core dumps could you please provide a gdb
backtrace for further investigation?

> 
> I haven't tried the poll-timeout, but would tend to agree with Paul on it's 
> usefulness.  Currently mod_jk doesn't flush on output (of course, it thinks 
> it's still httpd-1.3 and calls ap_rwrite, so maybe not the best example :).

I admit it is a bandaid until we have an improved protocol. The questions are

- Can we live with this bandaid
- When do we get the protocol update

> 
> The closest thing to the AJP/1.4 proposal would be:
>   http://tomcat.apache.org/connectors-doc/common/ajpv13ext.html

Thanks for the link.

> Of course, no Tomcat version currently supports it.  It wouldn't be that hard 
> to add a CMD_AJP13_FLUSH to Tomcat (with a Tomcat configuration option to turn 
> it off so it doesn't freak-out mod_jk :).  But as Will says, that discussion 
> belongs on dev@tomcat.
> 

Yes, this belongs to dev@tomcat. Are you willing to introduce this discussion to 
dev@tomcat? That would be very nice. On the other hand from my personal point of
view I do not think that it is a good idea to extend the Tomcat connectors in
this way without having this in a spec of an AJP protocol whatever version it
has. This would subvert the AJP spec.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org