Re: svn commit: r593943 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

[Rainer Jung]

Mladen Turk schrieb:
> [EMAIL PROTECTED] wrote:
>> Author: rjung
>> Date: Sun Nov 11 11:22:23 2007
>> New Revision: 593943
>>
>> URL: http://svn.apache.org/viewvc?rev=593943&view=rev
>> Log:
>> Undo revision 593927.
>> This produced a mem leak for vhosts with private JkMounts.
>> No idea why.
>>
> 
> Because uw_map is now allocated *only* if uri_to_context is
> allocated. In other cases uw_map is pointer to the parent
> allocated uw_map. So if you free uw_map with uri_to_context equals
> NULL, you'll actually have a double free of the same pointer.

The point was not a double free (crash), but a memory leak. I freed
uri_to_context in post_config and uw_map in the cleanup. Before freeing
I actually tested both against NULL.

To find out, where th eleak comes from, I also simply didn't initialize
uw_map and still had the leak!

When I didn't initialize uri_to_context in the JkMount config handler,
the leak went away.

With only uri_to_context used and uw_map artificially commented out, I
could open/close the leak by moving the free of uri_to_context from the
cleanup (OK) to post_config (bad). That's what I don't understand.

Regards,

Rainer

P.S.: I hope the other changes are fine with you?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r593943 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

[Mladen Turk]

Rainer Jung wrote:


P.S.: I hope the other changes are fine with you?



They look OK, but I'll double check, just in case ;)

Cheers,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r594160 - /tomcat/tc6.0.x/trunk/STATUS

[jfclere]

Author: jfclere
Date: Mon Nov 12 06:37:38 2007
New Revision: 594160

URL: http://svn.apache.org/viewvc?rev=594160&view=rev
Log:
Cast some votes.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=594160&r1=594159&r2=594160&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Nov 12 06:37:38 2007
@@ -57,9 +57,9 @@
   Includes: Version fix, Escape fix
   Excludes: Already quoted fix, vetoed in prev proposal
   +1: fhanik
-  -1: 
+  -1: jfclere TC doesn't pass TCK tests with your patch. +1 for the version 
part.
 
 * Fix licensing of JSP 2.1 schema
   svn diff -c r593814
-  +1: markt, remm
+  +1: markt, remm, jfclere
   -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r594192 - /tomcat/tc6.0.x/trunk/STATUS

[fhanik]

Author: fhanik
Date: Mon Nov 12 07:53:22 2007
New Revision: 594192

URL: http://svn.apache.org/viewvc?rev=594192&view=rev
Log:
proposing a third fix, still need to validate the value for escaping

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=594192&r1=594191&r2=594192&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Nov 12 07:53:22 2007
@@ -51,15 +51,20 @@
   and $Version parsing
   +1: jfclere, pero
   -1: markt - only the double quoting part - see 
http://marc.info/?l=tomcat-dev&m=119454915422424&w=2 for reasons
-  -1: fhanik - proposed patch 
http://people.apache.org/~fhanik/patches/cookies-fix.patch
-
-* Alternate Cookies fix - 
http://people.apache.org/~fhanik/patches/cookies-fix-2.patch
-  Includes: Version fix, Escape fix
-  Excludes: Already quoted fix, vetoed in prev proposal
-  +1: fhanik
-  -1: jfclere TC doesn't pass TCK tests with your patch. +1 for the version 
part.
+  -1: fhanik - proposed patch below
 
 * Fix licensing of JSP 2.1 schema
   svn diff -c r593814
   +1: markt, remm, jfclere
   -1:
+  
+* Fix cookie parsing, rev 3
+  Includes: Version fix, Escape fix, already quoted fix
+  It seems that the TCK doesn't do a good job at knowing what an escape 
character is.
+  Since the TCK does set an "already quoted" value, we should assume that that 
is how they interpret the cookie handling in the servlet spec
+  In this fix however, alreadyQuoted also checks for escaped values, and 
ignores them
+  http://people.apache.org/~fhanik/patches/cookies-fix-3.patch
+  +1: fhanik
+  -1: 
+  
+  
\ No newline at end of file



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41430] - JkOptions +ForwardDirectories with Apache's DirectoryIndex

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=41430





--- Additional Comments From [EMAIL PROTECTED]  2007-11-12 08:11 ---
A palatable hack for me was to touch index.do in my app. It's not pretty, but it
beats creating a JSP for my welcome-file-list to just redirect to a struts app.


-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43846] New: - Race condition with NIO connector parsing chunked response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=43846

   Summary: Race condition with NIO connector parsing chunked
response
   Product: Tomcat 6
   Version: 6.0.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: regression
  Priority: P2
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The problem seems to relate to parsing the body content when the **Transfer-
Encoding: chunked** header is present.  It appears that the chunk length gets
corrupted under load and the client is unable to parse the chunk out of the 
response body.

When the NIO connector parameter **socket.appWriteBufSize** is set to a value 
larger than the total response body, the error condition does not occur.

One might succesfully argue that this is proper performance tuning.  The Tomcat 
documents point out that to scale a large number of long held connections, the 
buffer sizes may need to be less than the response body (the memory footprint 
would be quite large otherwise).

Could there be a race condition involving the response buffering code?  

I have confirmed this behavior on both JDKs 1.5 and 1.6 on both Windows 2003 
and Linux.

Apache Bench does not appear to fully parse the response so it will not be 
helpful in reproducing the issue.   The Grinder framework does.  I am including 
the Grinder scripts so that the issue may be reproduced.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43846] - Race condition with NIO connector parsing chunked response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=43846





--- Additional Comments From [EMAIL PROTECTED]  2007-11-12 09:14 ---
Created an attachment (id=21114)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21114&action=view)
Jython/Grinder script

Jython script referenced from grinder properties file.   This script does most
of the interaction with the Tomcat server.  It is configured via a grinder
properties file.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43846] - Race condition with NIO connector parsing chunked response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=43846





--- Additional Comments From [EMAIL PROTECTED]  2007-11-12 09:16 ---
Created an attachment (id=21115)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21115&action=view)
Grinder properties file

Use this file as a starting point for your Grinder setup.  This defines the
number of threads, etc. to configure the test client.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43846] - Race condition with NIO connector parsing chunked response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=43846





--- Additional Comments From [EMAIL PROTECTED]  2007-11-12 09:20 ---
Created an attachment (id=21116)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21116&action=view)
Reponse generator servlet

This is a very simple Java servlet.  It generates a reponse body >8K.  This
somewhat larger response seems to render with Transfer-Encoding: chunked rather
than a Content-Length header.  This is what we want because the smaller
response bodies seem to work OK.  In the real world responses larger than 8K
are the norm.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r594231 - /tomcat/tc6.0.x/trunk/STATUS

[fhanik]

Author: fhanik
Date: Mon Nov 12 09:48:29 2007
New Revision: 594231

URL: http://svn.apache.org/viewvc?rev=594231&view=rev
Log:
revisiting the rules, new patch will come

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=594231&r1=594230&r2=594231&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Nov 12 09:48:29 2007
@@ -58,13 +58,3 @@
   +1: markt, remm, jfclere
   -1:
   
-* Fix cookie parsing, rev 3
-  Includes: Version fix, Escape fix, already quoted fix
-  It seems that the TCK doesn't do a good job at knowing what an escape 
character is.
-  Since the TCK does set an "already quoted" value, we should assume that that 
is how they interpret the cookie handling in the servlet spec
-  In this fix however, alreadyQuoted also checks for escaped values, and 
ignores them
-  http://people.apache.org/~fhanik/patches/cookies-fix-3.patch
-  +1: fhanik
-  -1: 
-  
-  
\ No newline at end of file



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43846] - Race condition with NIO connector parsing chunked response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=43846


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2007-11-12 10:53 ---
Thank you, I will take a look.
Filip

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43848] New: - SetCharaccterEncoding and Cached Parameters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=43848

   Summary: SetCharaccterEncoding and Cached Parameters
   Product: Tomcat 5
   Version: 5.5.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: critical
  Priority: P2
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hello,

I have discovered a behavior which I consider as a bug and would request it to
be reviewed.

Let me start by the source of the problem I had. We have English / Turkish
enabled web site that uses UTF-8 charset. I have a Filter that sets the encoding
to UTF-8 for all the request coming to tomcat to correctly handle not ascii
standard Turkish characters. However I saw that the
request.setCharachterEncoding(encoding) would not changed anything. It used to
work before and I suspected of a bug in my code.

Having spent 4 hours and trying different encodings, (UTF-8, ISO-8859-9,
ISO-8859-1) my forms with the Turkish characters stayed as corrupted.

Then to investigate it further, I dived into tomcat codes.

Then I discovered the following behavior:   
At any stage when the request's parameters is first accessed, all the parameters
parsed and cached.  There is nothing wrong with that. However, having accessed a
parameter at least once, if you try to set/change character encoding, encoding
is set without any warning/error/exception but is not effective as it directly
used at the time of parsing the parameters.

In my specific case, I have a filter that dumps all the properties of the
request (URL, headers, cookies, parameters and session attributes of the request
) for ease of development and this is the very first filter that a request
encounters, which accesses parameters of the request thus triggers caching of
the parameters.

Then the second filter sets the UTF-8 encoding to the request which has NO 
EFFECT.

Having searched the bug database, I have seen a lot of "encoding ignored" bugs.
I think a considerable amount of them might be related. I think the correct
behavior should be either expiration of the parsed parameter information cache
on encoding changes, or an exception needs to be thrown to indicate "it is too
late to change the encoding"

Unfortunately I haven't got the time check the servlet spec. So I may be
conflicting with the spec in my recommendations and if so my apologies for
misleading recommendations.

By the way I have tested this against 5.5.25 which is not listed in bugzilla!! 

Regards,
Hasan Ceylan

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]