Re: [ANN] Apache Tomcat 6.0.24 released
On 01/29/2010 03:29 AM, Jason Brittain wrote:
> Maybe you have a conflicting jsch jar file that ends up getting loaded in
> front of the
> correct/newer version. Look for all jsch jars on your machine and see what
> versions
> they are, and maybe temporarily (re)move older ones.
It seems I have one in ant and it uses this one :-/
Cheers
Jean-Frederic
>
> --
> Jason
>
>
> On Thu, Jan 28, 2010 at 6:25 PM, Filip Hanik - Dev Lists > wrote:
>
>> I get the error thrown by
>>
>> JSchException("Algorithm negotiation fail")
>>
>> and it says everywhere that it was fixed when MAven went to 2.1 (instead of
>> 2.0) but I still get it
>>
>> Filip
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48584] Error or ACCESS_VIOLATION on shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=48584 --- Comment #6 from Konstantin Kolinko 2010-01-29 05:13:15 UTC --- Created an attachment (id=24903) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24903) cycle.bat, Calls catalina start, catalina stop in a loop -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48584] Error or ACCESS_VIOLATION on shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=48584 --- Comment #7 from Konstantin Kolinko 2010-01-29 05:16:41 UTC --- Created an attachment (id=24904) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=24904) AprLifecycleListener_messages.patch, adds diagnostic messages to AprLifecycleListener#terminateAPR() -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48584] Error or ACCESS_VIOLATION on shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=48584 --- Comment #8 from Konstantin Kolinko 2010-01-29 06:02:09 UTC --- 1. When the crash happens, no event is recorded in the Event Viewer. I think that the crash is intercepted by JVM (that writes that crash report file) so the system does not know about it. The crash report file is written to the current working directory of java process. In my case it was %CATALINA_HOME%/bin, but it can be elsewhere. Though it might be, indeed, that 6.0.14 does not experience the crash. Thank you for the report. 2. Attachment 24903 - a batch file, that calls catalina start/stop in a cycle with some small delays. Even if I cannot always reproduce the error with several tries, I can reproduce it with the batch. 3. The message, that is printed by org.apache.tomcat.jni.Error, in English will be "A blocking operation was interrupted by a call to WSACancelBlockingCall" It is the message for the WSAEINTR socket error code, and means that some function call was interrupted, see http://support.microsoft.com/kb/819124 After playing a bit with the ".encoding" option of a FileHandler (in logging.properties) I was able to read it, but, indeed, TC-Native (or APR functions that it calls) does not respect system encoding. The message was processed with direct byte->char conversion, as if were in ISO-8859-1. By setting "1catalina.org.apache.juli.FileHandler.encoding = ISO-8859-1" and reading the log file with windows-1251 I was able to read it. It is wrong, but it is another issue. So, it looks that this error message is expected. What is wrong is that it generates a crash. 4. I tested with TC 7(trunk), where I added diagnostic messages around the AprLifecycleListener.terminateAPR() method - see attachment 24904. In the logs I see four variations of how the events happen: a) 29.01.2010 6:26:16 org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 29.01.2010 6:26:16 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminating APR 29.01.2010 6:26:16 org.apache.tomcat.util.net.AprEndpoint$Acceptor run SEVERE: Socket accept failed org.apache.tomcat.jni.Error: ??? WSACancelBlockingCall. at org.apache.tomcat.jni.Socket.accept(Native Method) at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:777) at java.lang.Thread.run(Unknown Source) 29.01.2010 6:26:16 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminated APR b) 29.01.2010 6:27:16 org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 29.01.2010 6:27:17 org.apache.tomcat.util.net.AprEndpoint$Acceptor run SEVERE: Socket accept failed org.apache.tomcat.jni.Error: ??? WSACancelBlockingCall. at org.apache.tomcat.jni.Socket.accept(Native Method) at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:777) at java.lang.Thread.run(Unknown Source) 29.01.2010 6:27:17 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminating APR 29.01.2010 6:27:17 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminated APR c) 29.01.2010 6:34:19 org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 29.01.2010 6:34:19 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminating APR 29.01.2010 6:34:19 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminated APR d) 29.01.2010 6:40:45 org.apache.coyote.ajp.AjpAprProtocol destroy INFO: Stopping Coyote AJP/1.3 on ajp-8009 29.01.2010 6:40:45 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminating APR 29.01.2010 6:40:45 org.apache.catalina.core.AprLifecycleListener terminateAPR INFO: Terminated APR 29.01.2010 6:40:45 org.apache.tomcat.util.net.AprEndpoint$Acceptor run SEVERE: Socket accept failed org.apache.tomcat.jni.Error: ??? WSACancelBlockingCall. at org.apache.tomcat.jni.Socket.accept(Native Method) at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:777) at java.lang.Thread.run(Unknown Source) When c) happens, a crash report file is generated. The AprLifecycleListener.terminateAPR() method calls o.a.t.jni.Library#terminate() that is implemented as a method in jnilib.c. TCN_IMPLEMENT_CALL(void, Library, terminate)(TCN_STDARGS) calls apr_pool_destroy(p); apr_terminate(); so if return from TCN_IMPLEMENT_CALL(jlong, Socket, accept)(TCN_STDARGS, jlong sock) of network.c happens after that call ends, as in d), it will face a destroyed pool and terminated APR. Thus it is no wonder that EXCEPTION_ACCESS_VIOLATION is reported. 5. So, the question is why org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:1156) was still running when AprLifecycleListener.terminateAPR() was already called. -- Configure bugmail: https://issues.apache.org/bugzil
svn commit: r904508 - /tomcat/trunk/java/org/apache/catalina/connector/Connector.java
Author: markt
Date: Fri Jan 29 14:50:45 2010
New Revision: 904508
URL: http://svn.apache.org/viewvc?rev=904508&view=rev
Log:
Minor cleanup
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Connector.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Connector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Connector.java?rev=904508&r1=904507&r2=904508&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Connector.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Connector.java Fri Jan 29
14:50:45 2010
@@ -69,8 +69,7 @@
// Constructor
-public Connector()
-throws Exception {
+public Connector() {
this(null);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn propchange: r892815 - svn:log
Author: markt Revision: 892815 Modified property: svn:log Modified: svn:log at Fri Jan 29 15:03:24 2010 -- --- svn:log (original) +++ svn:log Fri Jan 29 15:03:24 2010 @@ -4,3 +4,5 @@ - improved validation of WAR file names - make sure error messages match the action - the return from File.getCanonicalPath() may or may not return a final separator for directories + +This fixes CVE-2009-2693, CVE-2009-2901 & CVE-2009-2902 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn propchange: r892795 - svn:log
Author: markt Revision: 892795 Modified property: svn:log Modified: svn:log at Fri Jan 29 15:05:04 2010 -- --- svn:log (original) +++ svn:log Fri Jan 29 15:05:04 2010 @@ -4,3 +4,5 @@ - improved validation of WAR file names - make sure error messages match the action - the return from File.getCanonicalPath() may or may not return a final separator for directories + +This fixes CVE-2009-2693, CVE-2009-2901 & CVE-2009-2902 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48616] Struts 1.2 and bean:define tag throws jsp 1.1 regression exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=48616 DSEyers changed: What|Removed |Added OS/Version|Linux |All --- Comment #10 from DSEyers 2010-01-29 07:46:30 UTC --- We are also seeing the issue with our code running on Windows XP SP 2, 32bit OS using struts version 1.3.10. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48616] Struts 1.2 and bean:define tag throws jsp 1.1 regression exception
https://issues.apache.org/bugzilla/show_bug.cgi?id=48616 DSEyers changed: What|Removed |Added CC||dsey...@ntlworld.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: EL issues and 6.0.x release
2010/1/8 Mark Thomas :
> I think I have got to the bottom of why the EL has been so fragile and
> why the fixes to the various edge case bug fixes have invariably created
> new edge cases. It is probably easier to explain by considering an
> example. Using the echo tag from the newly added EL test cases consider
> the following JSP extract:
>
>
>
>
>
> The JSP and EL specs are a little fuzzy/inconsistent but the guidance we
> received from the expert group was:
> - the whole attribute should be unquoted as per the rules for quoting
> JSP attributes
> - everything outside an actual expression after unquoting should be
> treated as a literal
>
> The issue is that we performed JSP attribute unquoting and EL parsing in
> two independent steps. This creates an ambiguity. If the attribute
> values above are unquoted then we get the following:
>
> ${1+1}
> ${1+1}
> \${1+1}
>
> The first is an EL expression and will be treated as such.
> The second is a literal. However, the EL parser will treat it as an
> expression.
> The third is a literal '\' followed by an expression but the EL parser
> will see an escaped literal.
>
> My proposed solution is to modify the output of the attribute unquoting
> to ensure the EL Parser correctly interprets the result. ie:
> ${1+1}
> ${'$'}{1+1}
> ${'\'}${1+1}
>
Some more notes regarding this, as I am reviewing docs and
implementation in view of issues reported for 6.0.24.
Especially, I was looking at chapter JSP.10.1.11 (XML View /
"Request-Time Attribute Expressions") and especially the table Table
JSP.10-2 (XML View of an Escaped EL Expression) in that chapter of JSP
2.1 specification. The question was how it avoids the pitfall of bug
48627 [1]. More on that below.
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=48627
First, for reference: r899148 is the revision when the new
implementation was applied to the 6.0 branch [2].
[2] http://svn.apache.org/viewvc?view=revision&revision=899148
Highlights for that implementation:
#1. It fixes several EL parsing issues.
#2. It implements '\' -> ${'\\'} or #{'\\'} (depending on the
expression type) replacement
#1. is mainly implemented by the changes in ELParser.jjt file
#2. is mainly implemented by the new AttributeParser.java class
Especially #1. fixes the issue, where '\' in a literal EL expression
(ch. 1.2.2 of EL 2.1 spec) was interpreted as an escape character
(actually, it is not an escape character there, only \${ and \#{ ).
E.g., evaluation of "" as an EL expression should give "" and
not "\\". It gave '\\' before r899148. I mentioned that issue in [3].
The catch point here is that if that EL parsing issue is fixed in #1.,
then total unconditional replacement '\' -> ${'\\'} or #{'\\'} of #2.
is not needed. That is, with #1 being fixed a single '\' is correctly
evaluated as '\' by EL and does not need escaping.
Look at Table JSP.10-2 inchapter JSP.10.1.11 of JSP 2.1 spec, that I
mentioned. The "XML View" column there is always a valid EL
expression, with all necessary EL escaping. The rule there is that if
the resulting expression is a literal (all ${foo} are escaped as
\${foo}), then the '\'s are remaining as they are. If the resulting
expression is a composite EL expression (there is an unescaped ${foo}
there), only in that case '\'s are replaced with ${'\\'}.
That is, in that table the only lines where ${'\\'} is there are those
where the result is an evaluatable EL expression.
That avoids the pitfall of BZ 48627 (where "\\" value of an attribute
became an EL expression in a tag where dynamic expressions where not
allowed): all non-dynamic attributes remain as non-dynamic.
That also avoids the uncertainty of whether '\' should be escaped as
${'\\'} or as #{'\\'}. As eval EL-expression is always there in those
cases, we always know what type of expression ($ or #) it is.
[3] http://marc.info/?t=12626173356&r=1&w=2
Regarding the implementation, AttributeParser.java class. I think
that, based on the above, we can fix it to solve bug 48627. Other
parts of the new implementation will remain unchanged.
I have several comments on the AttributeParser class.
1. In JSP 2.1 spec there is an option to selectively disable '#'
expressions when '$' ones are still enabled. The name of that option
is "deferredSyntaxAllowedAsLiteral".
As of now, AttributeParser takes care of isELIgnored option, but does
not know about deferredSyntaxAllowedAsLiteral one.
2. There are several places in AttributeParser#parseLiteral() where
if (type == 0) {
type = '$';
}
That is where the bug 48627 lies. The above code turns non-dynamic
attribute in a dynamic one.
3. EL spec (ch.1.2.3 of EL 2.1 spec) says that "It is illegal to mix
${} and #{} constructs in a composite expression." though followed by
"This restriction may be lifted in future versions".
AttributeParser#parseLiteral() has the following clause:
} else if (ch == type){
I think it has to process '#'
