You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Petrashkova, Vera Y" <ve...@intel.com> on 2007/03/13 13:52:13 UTC
RE: [jira] Created: (HARMONY-3363) [DRLVM] contribution of alternative bytecode verifier
Cool!
Do I understand correct that VTS tests [1] that currently fail because
of unimplemented subroutine verification will now pass?
I'm going to run the DRLVM VTS to check how it impacts the pass rate
Thanks,
Vera
[1] http://issues.apache.org/jira/browse/HARMONY-3206
>---------- Forwarded message ----------
>From: Mikhail Loenko (JIRA) <ji...@apache.org>
>Date: 12.03.2007 16:55
>Subject: [jira] Created: (HARMONY-3363) [DRLVM] contribution of
>alternative bytecode verifier
>To: commits@harmony.apache.org
>
>
>[DRLVM] contribution of alternative bytecode verifier
>-----------------------------------------------------
>
> Key: HARMONY-3363
> URL: https://issues.apache.org/jira/browse/HARMONY-3363
> Project: Harmony
> Issue Type: New Feature
> Components: Contributions
> Reporter: Mikhail Loenko
>
>
>This is contribution of experimental bytecode verifier on behalf of
Intel.
>
>"Experimental" means that there is no formal proof currently available
>of its equivalence to the step-by-step verification algorithm
>described in the spec.
>
>The only known difference to the conventional verifier is dead code
>verification: RI makes stricter checks against dead code.
>Since it's about dead code, this difference does not affect
vulnerability
>
>Comparing to the current Harmony verifier, this one is supposed to be
>complete (Harmony currently does not support jsr/ret verification) and
>much faster
>
>So, I'm attaching 3 files:
>
>The first one: Verifier_bulk.zip is a bulk contribution on behalf of
>Intel for archiving purposes. It contains the legal files as well
>
>The second one: Verifier_patch is my fix to the bugs that I found
>while the first archive was coming thru legal
>
>The third archive Verifier_patched.zip is a merge for previous two.
>It's an up-to-date version for all the engineering purposes
>
>To try it out one should replace the current 'verifier' directory in
>vm with the new one and rebuild
>
>--
>This message is automatically generated by JIRA.
>-
>You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (HARMONY-1149) [classlib][regex] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
Posted by "Udovichenko, Nellya" <ne...@intel.com>.
Alexei, thank you very much!
Regards,
Nellya.
-----Original Message-----
From: Alexei Zakharov [mailto:alexei.zakharov@gmail.com]
Sent: Tuesday, March 20, 2007 4:52 PM
To: dev@harmony.apache.org
Subject: Re: [jira] Commented: (HARMONY-1149) [classlib][regex] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
Personally I agree to move this JIRA to Non-buf differences from RI.
So since there were no other voices I'm closing it.
Thanks,
2007/3/14, Udovichenko, Nellya <ne...@intel.com>:
> Hi,
> Can we close this JIRA as 'non-bug difference, won't fix'?
>
> I agree with Anton the issue is RI bug. In JDK 1.5 it allows one reference more than expected. May be the initial groups number is 1 instead 0. Therefore it doesn't correctly execute check-up of the back reference '\1' at regular expression parsing.
>
> Regards,
> Nellya.
>
>
> From "Anton Ivanov (JIRA)" <j....@apache.org>
> Subject [jira] Commented: (HARMONY-1149) [classlib][util] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
> Date Fri, 11 Aug 2006 08:50:14 GMT
> [ http://issues.apache.org/jira/browse/HARMONY-1149?page=comments#action_12427473 <http://issues.apache.org/jira/browse/HARMONY-1149?page=comments%23action_12427473%20> ]
>
> Anton Ivanov commented on HARMONY-1149:
> ---------------------------------------
>
> As you can see the problem arose while compiling regular expression "\\1" in the Pattern class.
> 1. To minimize the example you can write:
>
> import java.util.regex.*;
>
> public class test {
>
> public static void main (String [] args) {
> String str_re = "\\1";
>
> try {
> Pattern.compile(str_re);
> } catch (Exception e) {
> System.out.println("unexpected exception: " + e);
> }
> }
> }
>
> 2. As it is written in the API documentation for Pattern class "...сapturing groups are numbered
> by counting their opening parentheses from left to right..." and "...capturing groups are
> so named because, during a match, each subsequence of the input sequence that matches such
> a group is saved. The captured subsequence may be used later in the expression, via a back
> reference, and may also be retrieved from the matcher once the match operation is complete..."
> In the pattern "\\1" we have no yet group number 1 while compiling it, so backreference to
> the first group \1 is invalid.
> So we throw an exception.
> You can try to compile "\\2" string on RI and you will see the same situaution as for "\\1"
> on Harmony.
>
> 3. Another question is what backreference \1 should match while no such group in the pattern
> yet exists?
> For example if you write following on RI
>
> Pattern pat = Pattern.compile("\\1(c)");
> Matcher mat = pat.matcher("cc");
> if (mat.matches()) {
> System.out.println("matches");
> } else {
> System.out.println("not matches");
> }
>
> There will be the output "not matches"
> But if you change the first string to
>
> Pattern pat = Pattern.compile("(c)\\1");
>
> Then the output will be "matches".
> So backrefences to groups that do not yet exist are not processed as it may be expected.
> And again
>
> Pattern.compile("\\2(a)(b)");
>
> will cause an exception.
>
>
> I beleave this is a RI bug, not Harmony.
>
> > [classlib][util] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
> > -----------------------------------------------------------------------------------------
> >
> > Key: HARMONY-1149
> > URL: http://issues.apache.org/jira/browse/HARMONY-1149
> > Project: Harmony
> > Issue Type: Bug
> > Components: Classlib
> > Reporter: Vladimir Ivanov
> > Attachments: StringTest.patch
> >
> >
> > The Harmony methods String.replaceFirst(String regex, String replacement) and String.replaceAll(String
> regex, String replacement) throws PatternSyntaxException on Harmony and works silently on
> RI.
> > =================== test.java ======================
> > import java.util.regex.*;
> > public class test {
> > public static void main (String [] args) {
> > String str_re = "\\1";
> > try {
> > System.out.println("replaceFirst = " + "abc".replaceFirst(str_re, "x"));
> > } catch (Exception e) {
> > System.out.println("unexpected exception: " + e);
> > }
> > try {
> > System.out.println("replaceAll = " + "abc".replaceAll(str_re, "x"));
> > } catch (Exception e) {
> > System.out.println("unexpected exception: " + e);
> > e.printStackTrace();
> > }
> > }
> > }
> > ================================================
> > Output:
> > C:\tmp\tmp17>C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp . -showversion test
> > java version "1.5.0"
> > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> > BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, GC: System
> optimized over throughput (initial strategy singleparpar))
> > replaceFirst = abc
> > replaceAll = abc
> > C:\tmp\tmp17>C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp . -showversion
> test
> > java version 1.5 (subset)
> > (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable.
> > unexpected exception: java.util.regex.PatternSyntaxException: No such group yet exists
> at this point in the pattern near index: 0
> > \1
> > ^
> > unexpected exception: java.util.regex.PatternSyntaxException: No such group yet exists
> at this point in the pattern near index: 0
> > \1
> > ^
> > java.util.regex.PatternSyntaxException: No such group yet exists at this point in the
> pattern near index: 0
> > \1
> > ^
> > at java.util.regex.Pattern.processTerminal(Pattern.java:950)
> > at java.util.regex.Pattern.processSubExpression(Pattern.java:593)
> > at java.util.regex.Pattern.processExpression(Pattern.java:376)
> > at java.util.regex.Pattern.compileImpl(Pattern.java:279)
> > at java.util.regex.Pattern.compile(Pattern.java:261)
> > at java.util.regex.Pattern.compile(Pattern.java:1155)
> > at java.lang.String.replaceAll(String.java:1782)
> > at test.main(test.java:13)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Alexei Zakharov,
Intel ESSD
Re: [jira] Commented: (HARMONY-1149) [classlib][regex] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
Posted by Alexei Zakharov <al...@gmail.com>.
Personally I agree to move this JIRA to Non-buf differences from RI.
So since there were no other voices I'm closing it.
Thanks,
2007/3/14, Udovichenko, Nellya <ne...@intel.com>:
> Hi,
> Can we close this JIRA as 'non-bug difference, won't fix'?
>
> I agree with Anton the issue is RI bug. In JDK 1.5 it allows one reference more than expected. May be the initial groups number is 1 instead 0. Therefore it doesn't correctly execute check-up of the back reference '\1' at regular expression parsing.
>
> Regards,
> Nellya.
>
>
> From "Anton Ivanov (JIRA)" <j....@apache.org>
> Subject [jira] Commented: (HARMONY-1149) [classlib][util] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
> Date Fri, 11 Aug 2006 08:50:14 GMT
> [ http://issues.apache.org/jira/browse/HARMONY-1149?page=comments#action_12427473 <http://issues.apache.org/jira/browse/HARMONY-1149?page=comments%23action_12427473%20> ]
>
> Anton Ivanov commented on HARMONY-1149:
> ---------------------------------------
>
> As you can see the problem arose while compiling regular expression "\\1" in the Pattern class.
> 1. To minimize the example you can write:
>
> import java.util.regex.*;
>
> public class test {
>
> public static void main (String [] args) {
> String str_re = "\\1";
>
> try {
> Pattern.compile(str_re);
> } catch (Exception e) {
> System.out.println("unexpected exception: " + e);
> }
> }
> }
>
> 2. As it is written in the API documentation for Pattern class "...сapturing groups are numbered
> by counting their opening parentheses from left to right..." and "...capturing groups are
> so named because, during a match, each subsequence of the input sequence that matches such
> a group is saved. The captured subsequence may be used later in the expression, via a back
> reference, and may also be retrieved from the matcher once the match operation is complete..."
> In the pattern "\\1" we have no yet group number 1 while compiling it, so backreference to
> the first group \1 is invalid.
> So we throw an exception.
> You can try to compile "\\2" string on RI and you will see the same situaution as for "\\1"
> on Harmony.
>
> 3. Another question is what backreference \1 should match while no such group in the pattern
> yet exists?
> For example if you write following on RI
>
> Pattern pat = Pattern.compile("\\1(c)");
> Matcher mat = pat.matcher("cc");
> if (mat.matches()) {
> System.out.println("matches");
> } else {
> System.out.println("not matches");
> }
>
> There will be the output "not matches"
> But if you change the first string to
>
> Pattern pat = Pattern.compile("(c)\\1");
>
> Then the output will be "matches".
> So backrefences to groups that do not yet exist are not processed as it may be expected.
> And again
>
> Pattern.compile("\\2(a)(b)");
>
> will cause an exception.
>
>
> I beleave this is a RI bug, not Harmony.
>
> > [classlib][util] unexpected PatternSyntaxException for String.replaceFirst()/replaceAll()
> > -----------------------------------------------------------------------------------------
> >
> > Key: HARMONY-1149
> > URL: http://issues.apache.org/jira/browse/HARMONY-1149
> > Project: Harmony
> > Issue Type: Bug
> > Components: Classlib
> > Reporter: Vladimir Ivanov
> > Attachments: StringTest.patch
> >
> >
> > The Harmony methods String.replaceFirst(String regex, String replacement) and String.replaceAll(String
> regex, String replacement) throws PatternSyntaxException on Harmony and works silently on
> RI.
> > =================== test.java ======================
> > import java.util.regex.*;
> > public class test {
> > public static void main (String [] args) {
> > String str_re = "\\1";
> > try {
> > System.out.println("replaceFirst = " + "abc".replaceFirst(str_re, "x"));
> > } catch (Exception e) {
> > System.out.println("unexpected exception: " + e);
> > }
> > try {
> > System.out.println("replaceAll = " + "abc".replaceAll(str_re, "x"));
> > } catch (Exception e) {
> > System.out.println("unexpected exception: " + e);
> > e.printStackTrace();
> > }
> > }
> > }
> > ================================================
> > Output:
> > C:\tmp\tmp17>C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -cp . -showversion test
> > java version "1.5.0"
> > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> > BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, GC: System
> optimized over throughput (initial strategy singleparpar))
> > replaceFirst = abc
> > replaceAll = abc
> > C:\tmp\tmp17>C:\harmony\classlib1.5\deploy\jdk\jre\bin\java.exe -cp . -showversion
> test
> > java version 1.5 (subset)
> > (c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as applicable.
> > unexpected exception: java.util.regex.PatternSyntaxException: No such group yet exists
> at this point in the pattern near index: 0
> > \1
> > ^
> > unexpected exception: java.util.regex.PatternSyntaxException: No such group yet exists
> at this point in the pattern near index: 0
> > \1
> > ^
> > java.util.regex.PatternSyntaxException: No such group yet exists at this point in the
> pattern near index: 0
> > \1
> > ^
> > at java.util.regex.Pattern.processTerminal(Pattern.java:950)
> > at java.util.regex.Pattern.processSubExpression(Pattern.java:593)
> > at java.util.regex.Pattern.processExpression(Pattern.java:376)
> > at java.util.regex.Pattern.compileImpl(Pattern.java:279)
> > at java.util.regex.Pattern.compile(Pattern.java:261)
> > at java.util.regex.Pattern.compile(Pattern.java:1155)
> > at java.lang.String.replaceAll(String.java:1782)
> > at test.main(test.java:13)
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Alexei Zakharov,
Intel ESSD
Re: [jira] Created: (HARMONY-3363) [DRLVM] contribution of alternative bytecode verifier
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x299 day of Apache Harmony Vera Y. Petrashkova wrote:
> Here are the results of VTS tests running:
> 4320 VTS tests were run
> 4183 - passed on DRLVM
> 4234 - passed on DRLVM with alternative bytecode verifier
thanks a lot!
> Thanks,
> Vera Petrashkova
>
> >-----Original Message-----
> >From: Petrashkova, Vera Y [mailto:vera.y.petrashkova@intel.com]
> >Sent: Tuesday, March 13, 2007 6:52 PM
> >To: dev@harmony.apache.org
> >Subject: RE: [jira] Created: (HARMONY-3363) [DRLVM] contribution of
> >alternative bytecode verifier
> >
> >Cool!
> >
> >Do I understand correct that VTS tests [1] that currently fail because
> >of unimplemented subroutine verification will now pass?
> >
> >I'm going to run the DRLVM VTS to check how it impacts the pass rate
> >
> >Thanks,
> >Vera
> >
> >[1] http://issues.apache.org/jira/browse/HARMONY-3206
> >
> >>---------- Forwarded message ----------
> >>From: Mikhail Loenko (JIRA) <ji...@apache.org>
> >>Date: 12.03.2007 16:55
> >>Subject: [jira] Created: (HARMONY-3363) [DRLVM] contribution of
> >>alternative bytecode verifier
> >>To: commits@harmony.apache.org
> >>
> >>
> >>[DRLVM] contribution of alternative bytecode verifier
> >>-----------------------------------------------------
> >>
> >> Key: HARMONY-3363
> >> URL:
> https://issues.apache.org/jira/browse/HARMONY-3363
> >> Project: Harmony
> >> Issue Type: New Feature
> >> Components: Contributions
> >> Reporter: Mikhail Loenko
> >>
> >>
> >>This is contribution of experimental bytecode verifier on behalf of
> >Intel.
> >>
> >>"Experimental" means that there is no formal proof currently available
> >>of its equivalence to the step-by-step verification algorithm
> >>described in the spec.
> >>
> >>The only known difference to the conventional verifier is dead code
> >>verification: RI makes stricter checks against dead code.
> >>Since it's about dead code, this difference does not affect
> >vulnerability
> >>
> >>Comparing to the current Harmony verifier, this one is supposed to be
> >>complete (Harmony currently does not support jsr/ret verification) and
> >>much faster
> >>
> >>So, I'm attaching 3 files:
> >>
> >>The first one: Verifier_bulk.zip is a bulk contribution on behalf of
> >>Intel for archiving purposes. It contains the legal files as well
> >>
> >>The second one: Verifier_patch is my fix to the bugs that I found
> >>while the first archive was coming thru legal
> >>
> >>The third archive Verifier_patched.zip is a merge for previous two.
> >>It's an up-to-date version for all the engineering purposes
> >>
> >>To try it out one should replace the current 'verifier' directory in
> >>vm with the new one and rebuild
> >>
> >>--
> >>This message is automatically generated by JIRA.
> >>-
> >>You can reply to this email to add a comment to the issue online.
>
--
Egor Pasko
RE: [jira] Created: (HARMONY-3363) [DRLVM] contribution of alternative bytecode verifier
Posted by "Petrashkova, Vera Y" <ve...@intel.com>.
Here are the results of VTS tests running:
4320 VTS tests were run
4183 - passed on DRLVM
4234 - passed on DRLVM with alternative bytecode verifier
Thanks,
Vera Petrashkova
>-----Original Message-----
>From: Petrashkova, Vera Y [mailto:vera.y.petrashkova@intel.com]
>Sent: Tuesday, March 13, 2007 6:52 PM
>To: dev@harmony.apache.org
>Subject: RE: [jira] Created: (HARMONY-3363) [DRLVM] contribution of
>alternative bytecode verifier
>
>Cool!
>
>Do I understand correct that VTS tests [1] that currently fail because
>of unimplemented subroutine verification will now pass?
>
>I'm going to run the DRLVM VTS to check how it impacts the pass rate
>
>Thanks,
>Vera
>
>[1] http://issues.apache.org/jira/browse/HARMONY-3206
>
>>---------- Forwarded message ----------
>>From: Mikhail Loenko (JIRA) <ji...@apache.org>
>>Date: 12.03.2007 16:55
>>Subject: [jira] Created: (HARMONY-3363) [DRLVM] contribution of
>>alternative bytecode verifier
>>To: commits@harmony.apache.org
>>
>>
>>[DRLVM] contribution of alternative bytecode verifier
>>-----------------------------------------------------
>>
>> Key: HARMONY-3363
>> URL:
https://issues.apache.org/jira/browse/HARMONY-3363
>> Project: Harmony
>> Issue Type: New Feature
>> Components: Contributions
>> Reporter: Mikhail Loenko
>>
>>
>>This is contribution of experimental bytecode verifier on behalf of
>Intel.
>>
>>"Experimental" means that there is no formal proof currently available
>>of its equivalence to the step-by-step verification algorithm
>>described in the spec.
>>
>>The only known difference to the conventional verifier is dead code
>>verification: RI makes stricter checks against dead code.
>>Since it's about dead code, this difference does not affect
>vulnerability
>>
>>Comparing to the current Harmony verifier, this one is supposed to be
>>complete (Harmony currently does not support jsr/ret verification) and
>>much faster
>>
>>So, I'm attaching 3 files:
>>
>>The first one: Verifier_bulk.zip is a bulk contribution on behalf of
>>Intel for archiving purposes. It contains the legal files as well
>>
>>The second one: Verifier_patch is my fix to the bugs that I found
>>while the first archive was coming thru legal
>>
>>The third archive Verifier_patched.zip is a merge for previous two.
>>It's an up-to-date version for all the engineering purposes
>>
>>To try it out one should replace the current 'verifier' directory in
>>vm with the new one and rebuild
>>
>>--
>>This message is automatically generated by JIRA.
>>-
>>You can reply to this email to add a comment to the issue online.