[cp-patches] [PATCH] Fix Matcher.find() infinite loop bug
This patch fixes a problem in Match.find() where the following piece of code
would enter an infinite loop:
Pattern p = Pattern.compile(\u);
Matcher m = p.matcher(hello, world);
System.out.println(m.find());
Signed-off-by: Pekka Enberg penb...@kernel.org
---
ChangeLog|5 +
java/util/regex/Matcher.java |6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 05aa794..2b9cb5c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2011-03-02 Pekka Enberg penb...@kernel.org
+
+ * java/util/regex/Matcher:
+ (find): Make sure match is within input data limits.
+
2011-02-22 Pekka Enberg penb...@kernel.org
* java/util/HashMap:
diff --git a/java/util/regex/Matcher.java b/java/util/regex/Matcher.java
index be57471..86c4873 100644
--- a/java/util/regex/Matcher.java
+++ b/java/util/regex/Matcher.java
@@ -169,6 +169,12 @@ public final class Matcher implements MatchResult
if (match != null)
{
int endIndex = match.getEndIndex();
+// Is the match within input limits?
+if (endIndex = input.length())
+ {
+match = null;
+return false;
+ }
// Are we stuck at the same position?
if (!first endIndex == position)
{
--
1.7.1
Re: [cp-patches] [PATCH] Fix Matcher.find() infinite loop bug
On 16:22 Wed 02 Mar , Pekka Enberg wrote:
This patch fixes a problem in Match.find() where the following piece of code
would enter an infinite loop:
Pattern p = Pattern.compile(\u);
Matcher m = p.matcher(hello, world);
System.out.println(m.find());
Seems a sensible fix. Could you provide a testcase for Mauve for this too?
Signed-off-by: Pekka Enberg penb...@kernel.org
---
ChangeLog|5 +
java/util/regex/Matcher.java |6 ++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 05aa794..2b9cb5c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2011-03-02 Pekka Enberg penb...@kernel.org
+
+ * java/util/regex/Matcher:
+ (find): Make sure match is within input data limits.
+
2011-02-22 Pekka Enberg penb...@kernel.org
* java/util/HashMap:
diff --git a/java/util/regex/Matcher.java b/java/util/regex/Matcher.java
index be57471..86c4873 100644
--- a/java/util/regex/Matcher.java
+++ b/java/util/regex/Matcher.java
@@ -169,6 +169,12 @@ public final class Matcher implements MatchResult
if (match != null)
{
int endIndex = match.getEndIndex();
+// Is the match within input limits?
+if (endIndex = input.length())
+ {
+match = null;
+return false;
+ }
// Are we stuck at the same position?
if (!first endIndex == position)
{
--
1.7.1
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Mauve test gnu.testlet.java.lang.String.split stuck in infinite loop
Hi, I have not yet investigated, but it looks like the Mauve test gnu.testlet.java.lang.String.split gets stuck in an infinite loop (it runs fine on JDK 1.5). Could this be due to recent regexp changes? Regards, Jeroen
Bypassing security manager checks (was: Re: Infinite loop)
Michael Koch wrote: On Wed, Nov 16, 2005 at 11:56:37AM +, Gary Benson wrote: If your security policy denies read access to that system property The solution is to use gnu.classpath.SystemProperties.getProperty(...). This does no security check. It is exactly for such issues. Out of interest, what stops user code from calling such things? Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Bypassing security manager checks (was: Re: Infinite loop)
Gary Benson writes: Michael Koch wrote: On Wed, Nov 16, 2005 at 11:56:37AM +, Gary Benson wrote: If your security policy denies read access to that system property The solution is to use gnu.classpath.SystemProperties.getProperty(...). This does no security check. It is exactly for such issues. Out of interest, what stops user code from calling such things? Nothing. That's one of the bugs on the list. Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Bypassing security manager checks (was: Re: Infinite loop)
Andrew Haley wrote: Gary Benson writes: Michael Koch wrote: On Wed, Nov 16, 2005 at 11:56:37AM +, Gary Benson wrote: If your security policy denies read access to that system property The solution is to use gnu.classpath.SystemProperties.getProperty(...). This does no security check. It is exactly for such issues. Out of interest, what stops user code from calling such things? Nothing. That's one of the bugs on the list. That's not exactly true. The system class loader does enforce that user code cannot access classes in protected packages. It's just that we don't have the proper security configuration files in place to define the protected packages yet. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Bypassing security manager checks (was: Re: Infinite loop)
Jeroen Frijters wrote: Andrew Haley wrote: Gary Benson writes: Michael Koch wrote: The solution is to use gnu.classpath.SystemProperties.getProperty(...). This does no security check. It is exactly for such issues. Out of interest, what stops user code from calling such things? Nothing. That's one of the bugs on the list. That's not exactly true. The system class loader does enforce that user code cannot access classes in protected packages. It's just that we don't have the proper security configuration files in place to define the protected packages yet. You make it sound like an easy fix: is it? What needs to be done, and where? Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Bypassing security manager checks (was: Re: Infinite loop)
Gary Benson wrote: That's not exactly true. The system class loader does enforce that user code cannot access classes in protected packages. It's just that we don't have the proper security configuration files in place to define the protected packages yet. You make it sound like an easy fix: is it? What needs to be done, and where? The security properties file needs a line: package.access=gnu.classpath. and the security policy should not include RuntimePermission(accessClassInPackage.gnu.classpath). Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Bypassing security manager checks (was: Re: Infinite loop)
On Thu, 2005-11-17 at 13:42 +, Gary Benson wrote: You make it sound like an easy fix: is it? What needs to be done, and where? Besides what Jeroen already said you also have to merge ClassLoader. libgcj has a different version at the moment. In particular you want the logic that createSystemClassLoader() has. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Bypassing security manager checks (was: Re: Infinite loop)
Mark Wielaard wrote: On Thu, 2005-11-17 at 13:42 +, Gary Benson wrote: You make it sound like an easy fix: is it? What needs to be done, and where? Besides what Jeroen already said you also have to merge ClassLoader. libgcj has a different version at the moment. In particular you want the logic that createSystemClassLoader() has. For the time being I'm developing with Classpath HEAD and JamVM. GCJ is much more unwieldy, with no gain for general hacking like I'm doing at the moment. Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[cp-patches] Patch: infinite loop in security manager
Michael Koch wrote:
On Wed, Nov 16, 2005 at 11:56:37AM +, Gary Benson wrote:
I found a bug where the thing that throws SecurityExceptions can
itself cause a SecurityException to be thrown causing an infinite
loop.
When java.security.AccessControlContext.checkPermission decides
that a permission is denied it throws the exception with the
following line:
throw new AccessControlException (permission
+ perm
+ not granted:
+ domain
+ does not imply it.);
Where domain is a java.security.ProtectionDomain, whose
toString() method calls System.getProperty(line.separator). If
your security policy denies read access to that system property
then it's going to end up trying to throw the same
AccessControlException and failing to access line.separator again,
ad infinitum (until you run out of stack).
I wasn't sure quite how best to fix this so I haven't made a patch.
The solution is to use gnu.classpath.SystemProperties.getProperty(...).
This does no security check. It is exactly for such issues.
Sure, here you are.
Cheers,
Gary
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.5612
diff -u -r1.5612 ChangeLog
--- ChangeLog 15 Nov 2005 23:07:23 - 1.5612
+++ ChangeLog 16 Nov 2005 12:51:26 -
@@ -1,3 +1,9 @@
+2005-11-16 Gary Benson [EMAIL PROTECTED]
+
+ * java/security/ProtectionDomain.java (toString): Use
+ gnu.classpath.SystemProperties to read line.separator
+ without security manager check.
+
2005-11-15 Roman Kennke [EMAIL PROTECTED]
* javax/swing/JComponent.java
Index: java/security/ProtectionDomain.java
===
RCS file: /cvsroot/classpath/classpath/java/security/ProtectionDomain.java,v
retrieving revision 1.13
diff -u -r1.13 ProtectionDomain.java
--- java/security/ProtectionDomain.java 2 Jul 2005 20:32:40 - 1.13
+++ java/security/ProtectionDomain.java 16 Nov 2005 12:51:26 -
@@ -37,6 +37,8 @@
package java.security;
+import gnu.classpath.SystemProperties;
+
/**
* pThis codeProtectionDomain/code class encapsulates the characteristics
* of a domain, which encloses a set of classes whose instances are granted a
@@ -222,7 +224,7 @@
*/
public String toString()
{
-String linesep = System.getProperty(line.separator);
+String linesep = SystemProperties.getProperty(line.separator);
StringBuffer sb = new StringBuffer(ProtectionDomain ().append(linesep);
if (code_source == null)
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: infinite loop in security manager
Hi Gary, On Wed, 2005-11-16 at 12:54 +, Gary Benson wrote: +2005-11-16 Gary Benson [EMAIL PROTECTED] + + * java/security/ProtectionDomain.java (toString): Use + gnu.classpath.SystemProperties to read line.separator + without security manager check. Cool thanks. Checked in. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Infinite loop
I found a bug where the thing that throws SecurityExceptions can itself cause a SecurityException to be thrown causing an infinite loop. When java.security.AccessControlContext.checkPermission decides that a permission is denied it throws the exception with the following line: throw new AccessControlException (permission + perm + not granted: + domain + does not imply it.); Where domain is a java.security.ProtectionDomain, whose toString() method calls System.getProperty(line.separator). If your security policy denies read access to that system property then it's going to end up trying to throw the same AccessControlException and failing to access line.separator again, ad infinitum (until you run out of stack). I wasn't sure quite how best to fix this so I haven't made a patch. Cheers, Gary ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
On Wed, Nov 16, 2005 at 11:56:37AM +, Gary Benson wrote: I found a bug where the thing that throws SecurityExceptions can itself cause a SecurityException to be thrown causing an infinite loop. When java.security.AccessControlContext.checkPermission decides that a permission is denied it throws the exception with the following line: throw new AccessControlException (permission + perm + not granted: + domain + does not imply it.); Where domain is a java.security.ProtectionDomain, whose toString() method calls System.getProperty(line.separator). If your security policy denies read access to that system property then it's going to end up trying to throw the same AccessControlException and failing to access line.separator again, ad infinitum (until you run out of stack). I wasn't sure quite how best to fix this so I haven't made a patch. The solution is to use gnu.classpath.SystemProperties.getProperty(...). This does no security check. It is exactly for such issues. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
On Wednesday 16 November 2005 12:56, Gary Benson wrote: Where domain is a java.security.ProtectionDomain, whose toString() method calls System.getProperty(line.separator). If your security policy denies read access to that system property then it's going to end up trying to throw the same AccessControlException and failing to access line.separator again, ad infinitum (until you run out of stack). I'd say that the toString should never throw that exception (the spec does not do that either). So either catch it in the toString or default to '\n' -- Thomas Zander pgpW5Dc7wzYlQ.pgp Description: PGP signature ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[cp-patches] VMStackWalker infinite loop fix
I've committed the attached patch to fix an infinite loop between VMStackWalker.getCallingClassLoader() and Class.getClassLoader(). 2005-11-13 Archie Cobbs [EMAIL PROTECTED] * vm/reference/gnu/classpath/VMStackWalker.java (getClassLoader()): added to fix an infinite loop bug. * NEWS: note VM interface change. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: NEWS === RCS file: /cvsroot/classpath/classpath/NEWS,v retrieving revision 1.104 diff -u -r1.104 NEWS --- NEWS2 Nov 2005 22:31:47 - 1.104 +++ NEWS13 Nov 2005 22:25:48 - @@ -1,3 +1,10 @@ +New in release 0.20 + +Runtime interface changes: + +* New method VMStackWalker.getClassLoader() was added to avoid an infinite + loop between getCallingClassLoader() and Class.getClassLoader(). + New in release 0.19 (Nov 2, 2005) * The Swing RepaintManager has been reworked for more efficient painting, Index: vm/reference/gnu/classpath/VMStackWalker.java === RCS file: /cvsroot/classpath/classpath/vm/reference/gnu/classpath/VMStackWalker.java,v retrieving revision 1.5 diff -u -r1.5 VMStackWalker.java --- vm/reference/gnu/classpath/VMStackWalker.java 2 Jul 2005 20:33:08 - 1.5 +++ vm/reference/gnu/classpath/VMStackWalker.java 13 Nov 2005 22:25:51 - @@ -88,9 +88,9 @@ /** * Get the class loader associated with the Class returned by - * codegetCallingClass()/code, or codenull/code if no - * such class exists or it is the boot loader. This method is an optimization - * for the expression codegetClassContext()[1].getClassLoader()/code + * codegetCallingClass()/code, or codenull/code if no such class + * exists or it is the boot loader. This method is an optimization for the + * expression codeVMStackWalker.getClassLoader(getClassContext()[1])/code * and should return the same result. * * p @@ -102,7 +102,15 @@ Class[] ctx = getClassContext(); if (ctx.length 3) return null; -return ctx[2].getClassLoader(); +return getClassLoader(ctx[2]); } + + /** + * Retrieve the class's ClassLoader, or codenull/code if loaded + * by the bootstrap loader. I.e., this should return the same thing + * as [EMAIL PROTECTED] java.lang.VMClass#getClassLoader}. This duplicate version + * is here to work around access permissions. + */ + public static native ClassLoader getClassLoader(Class cl); } ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
RE: Infinite loop
Archie Cobbs wrote: I'm adapting JCVM to work with a totally unmodified Classpath, but doing so seems to cause an infinite loop in Mauve test gnu.testlet.java.util.logging.Logger.getAnonymousLogger. The infinite loop is simple: Class.getClassLoader() invokes VMStackWalker.getCallingClassLoader() VMStackWalker.getCallingClassLoader() invokes Class.getClassLoader() It would be nice if VMStackWalker.getCallingClassLoader() could invoke VMClass.getClassLoader(), but access permissions prevent that. Any ideas? One idea is to move VMStackWalker into java.lang. We can't do that, it needs to be public. I guess that VMStackWalker should have a native method to get the class loader from a Class. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Jeroen Frijters wrote: The infinite loop is simple: Class.getClassLoader() invokes VMStackWalker.getCallingClassLoader() VMStackWalker.getCallingClassLoader() invokes Class.getClassLoader() It would be nice if VMStackWalker.getCallingClassLoader() could invoke VMClass.getClassLoader(), but access permissions prevent that. Any ideas? One idea is to move VMStackWalker into java.lang. We can't do that, it needs to be public. I guess that VMStackWalker should have a native method to get the class loader from a Class. Sounds good.. how about this? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com Index: VMStackWalker.java === RCS file: /cvsroot/classpath/classpath/vm/reference/gnu/classpath/VMStackWalker.java,v retrieving revision 1.5 diff -u -r1.5 VMStackWalker.java --- VMStackWalker.java 2 Jul 2005 20:33:08 - 1.5 +++ VMStackWalker.java 9 Nov 2005 17:44:29 - @@ -88,9 +88,9 @@ /** * Get the class loader associated with the Class returned by - * codegetCallingClass()/code, or codenull/code if no - * such class exists or it is the boot loader. This method is an optimization - * for the expression codegetClassContext()[1].getClassLoader()/code + * codegetCallingClass()/code, or codenull/code if no such class + * exists or it is the boot loader. This method is an optimization for the + * expression codeVMStackWalker.getClassLoader(getClassContext()[1])/code * and should return the same result. * * p @@ -102,7 +102,15 @@ Class[] ctx = getClassContext(); if (ctx.length 3) return null; -return ctx[2].getClassLoader(); +return getClassLoader(ctx[2]); } + + /** + * Retrieve the class's ClassLoader, or codenull/code if loaded + * by the bootstrap loader. I.e., this should return the same thing + * as [EMAIL PROTECTED] java.lang.VMClass#getClassLoader}. This duplicate version + * is here to work around access permissions. + */ + public static native ClassLoader getClassLoader(Class cl); } ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Seems like we could remove VMClass.getClassLoader altogether then since it's public and static in VMStackWalker? On the other hand, should it be public in VMStackWalker? Is that ok from a security standpoint? Stuart. -- http://sab39.dev.netreach.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
Stuart Ballard wrote: Seems like we could remove VMClass.getClassLoader altogether then since it's public and static in VMStackWalker? Yes, I suppose so... On the other hand, should it be public in VMStackWalker? Is that ok from a security standpoint? Yes.. all the other methods in there are too. VMStackWalker can only be used by classes loaded via the boot loader (see comment at the top). -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Infinite loop
On Wed, 2005-11-09 at 14:12 -0600, Archie Cobbs wrote: Stuart Ballard wrote: Seems like we could remove VMClass.getClassLoader altogether then since it's public and static in VMStackWalker? Yes, I suppose so... I can imagine a vm optimizing VMClass.getClassLoader() differently from VmStackWalker.getClassLoader(). So I would keep them both just in case. Unless you think that is really messy or a really far fetched optimization oppertunity. On the other hand, should it be public in VMStackWalker? Is that ok from a security standpoint? Yes.. all the other methods in there are too. VMStackWalker can only be used by classes loaded via the boot loader (see comment at the top). I must admit that it took me also a bit of thinking why this is safe. A user defined class loader loadClass() method needs to handle SecurityManager.checkPackageAccess() when a security manager is installed. And since any class can only access another class through loading the class directly or indirectly through its own class loader this can be used to deny any access to classes not loaded by the bootstrap class loader. See the GNU Classpath ClassLoader createSystemClassLoader() method for an example of how this works. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug swing/23966] New: JInternalFrame mouse moved infinite loop
Run the testcase below and move the mouse to be in the main section of the
JInternalFrame (not the title bar part, the content part). Out of Memory errors
occur as the mouse moved event gets infinitely passed around.
***TESCASE***
import javax.swing.*;
public class Test
{
public static void main(String[] args)
{
JFrame jf = new JFrame();
JLayeredPane jl = new JLayeredPane();
jf.setLayeredPane (jl);
jf.setSize(600,600);
JInternalFrame frame = new JInternalFrame(title2, true, true, true, true);
jf.setContentPane(frame);
frame.show();
jf.show();
frame.setSize(100,100);
}
}
--
Summary: JInternalFrame mouse moved infinite loop
Product: classpath
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: swing
AssignedTo: abalkiss at redhat dot com
ReportedBy: abalkiss at redhat dot com
CC: bug-classpath at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23966
___
Bug-classpath mailing list
Bug-classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-classpath
