[Bug libgcj/27908] New: VMSecureRandom generateSeed infinite loop? (Regression)

[Bug libgcj/27908] New: VMSecureRandom generateSeed infinite loop? (Regression)

[r_ovidius at eml dot cc]

gcc version 4.2.0 20060605 (experimental)

I'm trying to run jsch (jcraft.com) with the examples/PortForwardingR.java and
id_dsa identity.  It worked before the most recent classpath import (works in
gcj 20060420), but now it just results in an infinite loop and a pegged cpu.

My guess is that it spins forever in the SecureRandom call to
VMSecureRandom.generateSeed.  This class didn't exist in 20060420 but jsch
worked fine.

I'm not sure if it is classpath or bad code generation in gcj causing the
infinite loop.

This testcase pegs the cpu.  Works fine with Sun's java.
---
import java.security.*;
public class GR {
  public static void main(String[] a) {
    SecureRandom sr = new SecureRandom();
    byte[] ba = sr.getSeed(5);
    System.err.println(ba);
  } 
}


-- 
           Summary: VMSecureRandom generateSeed infinite loop? (Regression)
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: r_ovidius at eml dot cc


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #1 from csm at gnu dot org  2006-06-06 06:42 -------
This is apparently caused by the default implementation of VMSecureRandom,
which uses some threads concurrently modifying counters, and uses those
counters to construct random bytes.

It's odd that on GCJ this runs so slow; using the jamvm interpreter I didn't
notice that much of a lag (on a fast machine, sure, but I wouldn't think that
on any reasonably modern machine someone would get bothered enough to file a
bug).


-- 

csm at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |csm at gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-06 06:42:00
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #2 from csm at gnu dot org  2006-06-06 20:07 -------
I don't see any pegged CPU usage with 4.2.0 20060606, on a dual AMD Athlon
system, Linux 2.6.6, NPTL threads. The test case does seem to hang, however,
after the seed is generated (it takes about a second for the result to be
printed).

There may be something going wrong with threads and the calls to
Thread.yield(). Can you describe the systems you are running this test case on?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #3 from csm at gnu dot org  2006-06-06 20:14 -------
Also, a good workaround (on Linux and other Unices) is to add this line to your
classpath.security file:

  securerandom.source=file:/dev/random

This is generally a good idea. If you have available some file or device that
you can read random bytes out of, you should read that for PRNG seeds, instead
of using the fallback implementation in VMSecureRandom. Note that you can even
set that variable to an http URL, such as HotBits.

You can also use the system property `java.security.egd'. It, too, takes a URL.

For systems without /dev/random, you may have some luck with the entropy
gathering daemon, http://egd.sourceforge.net/.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[r_ovidius at eml dot cc]

------- Comment #4 from r_ovidius at eml dot cc  2006-06-06 20:20 -------
Linux RH9 2.4.20 450Mhz
WinXP 2Ghz

I removed the call to VMSecureRandom from SecureRandom and just return length
at the moment, and everything works again.  The usage of /dev/random did work
as well, but binaries would not be portable if target systems don't have it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #5 from csm at gnu dot org  2006-06-06 21:29 -------
On futher inspection, it is pegging my CPU as well. `top' was lying to me.

It *looks* as though the test `while (running)' may have been optimized away,
because the threads continue to run even after the `running' variable has been
set to false.

The attached test case seems to illustrate the problem, and it looks like a GCJ
bug. This test case:

  - Fails to exit when compiled with GCJ 20060606. Command line: gcj -g -O2 -o
PR27908 
  - Fails to run interpreted when compiled with 'gcj -C'. Error is
'java.lang.IllegalAccessError: PR27908: PR27908$run1.stop()V'.
  - Fails to run on Sun Java 1.5.0_03 on GNU/Linux x86 if compiled with 'gcj
-C'. Error is 'java.lang.VerifyError: (class: PR27908, method: main signature:
([Ljava/lang/String;)V) Illegal use of nonvirtual function call'.
  - Fails to run on jamvm if compiled 'gcj -C'. Error is similar to that on
gij: an IllegalAccessError.

This test case runs fine if compiled with Sun's 'javac -source 1.4 -target 1.4'
on both gij, java, and jamvm.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug libgcj/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #6 from csm at gnu dot org  2006-06-06 21:30 -------
Created an attachment (id=11613)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11613&action=view)
Test case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #7 from csm at gnu dot org  2006-06-06 21:32 -------
Also note that this test case works fine if compiled to a native binary (C++
ABI) with -O1. So there are likely two bugs here: an optimization issue, and a
bytecode generation issue.


-- 

csm at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libgcj                      |java
           Keywords|                            |wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #8 from csm at gnu dot org  2006-06-07 00:08 -------
A workaround is to replace:

  while (running)
    counter++;

with:

  while (isRunning ())
    counter++;

And to add a method:

  boolean isRunning ()
  {
    return running;
  }

I'm working on a patch for this.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-06-07 00:14 -------
(In reply to comment #8)
> A workaround is to replace:
> 
>   while (running)
>     counter++;

Is running marked as volatile?
If it is, then this is a dup of bug 1305, otherwise this is a bug in both the
library sources and still a dup of bug 1305 after that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #10 from csm at gnu dot org  2006-06-07 02:52 -------
Duplicate of bug 1305. A workaround for this case exists.

The bytecode problem mentioned below has been filed as bug 27925.

*** This bug has been marked as a duplicate of 1305 ***


-- 

csm at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[r_ovidius at eml dot cc]

------- Comment #11 from r_ovidius at eml dot cc  2006-06-07 03:16 -------
Alright, but, it seems strange that code that worked 2 months ago is suddenly
broken due to a bug filed 6 years ago.  The "Regression" status of this
particular situation and this particular code seems to get lost when calling it
a dupe.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2006-06-07 03:23 -------
(In reply to comment #11)
> Alright, but, it seems strange that code that worked 2 months ago is suddenly
> broken due to a bug filed 6 years ago.  The "Regression" status of this
> particular situation and this particular code seems to get lost when calling it
> a dupe.

The code changed which caused PR 1305 to show its head, csm posted a workaround
to the java-patches list so someone will most likely apply it.
And the regression part of this bug is not lost by calling the bug as a dup
because the work around was posted.

Yes it is semi weird an old bug to show its head causing this regression when
the library changes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[csm at gnu dot org]

------- Comment #13 from csm at gnu dot org  2006-06-07 04:49 -------
Very little (I'd assume no) code in Classpath requires that the `volatile'
modifier be properly supported. 0.91 introduced a class that did, that's all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

------- Comment #14 from aph at gcc dot gnu dot org  2006-06-13 12:44 -------
Subject: Bug 27908

Author: aph
Date: Tue Jun 13 12:43:56 2006
New Revision: 114609

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114609
Log:
2006-06-09  Andrew Haley  <aph@redhat.com>

        PR java/1305
        PR java/27908
        * builtins.c (initialize_builtins): Add __sync_synchronize().
        * class.c (add_field): Mark volatile fields.
        * java-gimplify.c (java_gimplify_expr): Call new functions to
        handle self-modifying exprs and COMPONENT_REFs.
        (java_gimplify_component_ref): New.
        (java_gimplify_modify_expr): Add handling for volatiles.


Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/builtins.c
    trunk/gcc/java/class.c
    trunk/gcc/java/java-gimplify.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

------- Comment #15 from aph at gcc dot gnu dot org  2006-06-19 17:38 -------
Subject: Bug 27908

Author: aph
Date: Mon Jun 19 17:38:08 2006
New Revision: 114778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114778
Log:
2006-06-19  Andrew Haley  <aph@redhat.com>

        PR java/1305
        PR java/27908
        * expr.c (java_modify_addr_for_volatile): New function.
        (expand_java_field_op): Handle volatile fields.
        * java-gimplify.c (java_gimplify_component_ref): Call
        java_modify_addr_for_volatile to give the field_ref the correct
        volatile type.
        (java_gimplify_modify_expr): Likewise.
        * java-tree.h (java_modify_addr_for_volatile): New decl.


Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/expr.c
    trunk/gcc/java/java-gimplify.c
    trunk/gcc/java/java-tree.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

------- Comment #16 from aph at gcc dot gnu dot org  2007-09-04 14:00 -------
Subject: Bug 27908

Author: aph
Date: Tue Sep  4 14:00:06 2007
New Revision: 128082

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128082
Log:
2007-09-04  Andrew Haley  <aph@redhat.com>

        PR java/27908
        * testsuite/libjava.lang/PR27908.java
        ({run1,run2,run3}.isRunning): New Method.
        (main): Fix race condition.

Modified:
    branches/gcj/gcj-eabi-branch/libjava/ChangeLog
    branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/PR27908.jar
    branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/PR27908.java


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

------- Comment #17 from aph at gcc dot gnu dot org  2007-09-04 17:55 -------
Subject: Bug 27908

Author: aph
Date: Tue Sep  4 17:54:56 2007
New Revision: 128094

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128094
Log:
2007-09-04  Andrew Haley  <aph@redhat.com>

        PR java/27908
        * testsuite/libjava.lang/PR27908.java
        ({run1,run2,run3}.isRunning): New Method.
        (main): Fix race condition.


Added:
    trunk/libjava/testsuite/libjava.lang/Foo.class
      - copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/Foo.class
    trunk/libjava/testsuite/libjava.lang/WalkerTest.jar
      - copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.jar
    trunk/libjava/testsuite/libjava.lang/WalkerTest.java
      - copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.java
    trunk/libjava/testsuite/libjava.lang/WalkerTest.out
      - copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/testsuite/libjava.lang/WalkerTest.out
Modified:
    trunk/libjava/testsuite/libjava.lang/PR27908.jar
    trunk/libjava/testsuite/libjava.lang/PR27908.java


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

------- Comment #18 from aph at gcc dot gnu dot org  2007-09-04 17:58 -------
Subject: Bug 27908

Author: aph
Date: Tue Sep  4 17:57:52 2007
New Revision: 128097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128097
Log:
2007-09-04  Andrew Haley  <aph@redhat.com>

        PR java/27908
        * testsuite/libjava.lang/PR27908.java
        ({run1,run2,run3}.isRunning): New Method.
        (main): Fix race condition.

2007-08-29  Andrew Haley  <aph@redhat.com>

        * gnu/classpath/natVMStackWalker.cc (VMStackWalker::getCallingClass):
        Make sure we're not sibcalled.
        (GET_CALLING_CLASS): Define for ARM EABI.

2007-08-22  Andrew Haley  <aph@redhat.com>

        * configure.host (BACKTRACESPEC): Add arm*-linux*.

2007-08-22  Andrew Haley  <aph@redhat.com>

        * configure.ac (LIBSTDCXXSPEC): New.
        * configure.host: Add arm*-linux* to pthread test.
        * configure.ac (LIBGCJTESTSPEC): Add path to libstdc++ for ARM
        EABI.
        * testsuite/libjava.jni/jni.exp (gcj_jni_compile_c_to_so): Use
        -fexceptions for ARM EABI.
        * testsuite/lib/libjava.exp (libjava_arguments): Add libgcj-test.spec.
        (libjava_invoke): Log the invocation.

2007-08-15  Andrew Haley  <aph@redhat.com>

        * configure.ac (extra_ldflags): Define.
        * Makefile.am: Use extra_ldflags for all executables.

2007-08-14  Andrew Haley  <aph@redhat.com>

        * sysdep/arm/backtrace.h: Remove stubs for _Unwind_GetIPInfo,
        _Unwind_GetRegionStart, and _Unwind_Backtrace.

2007-07-27  Andrew Haley  <aph@redhat.com>

        * gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): Stub for
        ARM EABI.
        * exception.cc (get_exception_header_from_ue): New.
        (get_ttype_entry): ARM EABI version.
        (PERSONALITY_FUNCTION): Add ARM EABI code.
        * sysdep/arm/backtrace.h: New file.
        * stacktrace.cc (_URC_NORMAL_STOP): New.
        * configure.ac (extra_ldflags_libjava): Add libsupc++.la for ARM
        EABI.
        * configure.host (BACKTRACESPEC): Add arm/backtrace.h.

Modified:
    trunk/libjava/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908

[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)

[aph at gcc dot gnu dot org]

------- Comment #19 from aph at gcc dot gnu dot org  2007-09-04 18:00 -------
Subject: Bug 27908

Author: aph
Date: Tue Sep  4 18:00:31 2007
New Revision: 128098

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128098
Log:
2007-09-04  Andrew Haley  <aph@redhat.com>

        PR java/27908
        * testsuite/libjava.lang/PR27908.java
        ({run1,run2,run3}.isRunning): New Method.
        (main): Fix race condition.

2007-08-29  Andrew Haley  <aph@redhat.com>

        * gnu/classpath/natVMStackWalker.cc (VMStackWalker::getCallingClass):
        Make sure we're not sibcalled.
        (GET_CALLING_CLASS): Define for ARM EABI.

2007-08-22  Andrew Haley  <aph@redhat.com>

        * configure.host (BACKTRACESPEC): Add arm*-linux*.

2007-08-22  Andrew Haley  <aph@redhat.com>

        * configure.ac (LIBSTDCXXSPEC): New.
        * configure.host: Add arm*-linux* to pthread test.
        * configure.ac (LIBGCJTESTSPEC): Add path to libstdc++ for ARM
        EABI.
        * testsuite/libjava.jni/jni.exp (gcj_jni_compile_c_to_so): Use
        -fexceptions for ARM EABI.
        * testsuite/lib/libjava.exp (libjava_arguments): Add libgcj-test.spec.
        (libjava_invoke): Log the invocation.

2007-08-15  Andrew Haley  <aph@redhat.com>

        * configure.ac (extra_ldflags): Define.
        * Makefile.am: Use extra_ldflags for all executables.

2007-08-14  Andrew Haley  <aph@redhat.com>

        * sysdep/arm/backtrace.h: Remove stubs for _Unwind_GetIPInfo,
        _Unwind_GetRegionStart, and _Unwind_Backtrace.

2007-07-27  Andrew Haley  <aph@redhat.com>

        * gnu/classpath/natVMStackWalker.cc (GET_CALLING_CLASS): Stub for
        ARM EABI.
        * exception.cc (get_exception_header_from_ue): New.
        (get_ttype_entry): ARM EABI version.
        (PERSONALITY_FUNCTION): Add ARM EABI code.
        * sysdep/arm/backtrace.h: New file.
        * stacktrace.cc (_URC_NORMAL_STOP): New.
        * configure.ac (extra_ldflags_libjava): Add libsupc++.la for ARM
        EABI.
        * configure.host (BACKTRACESPEC): Add arm/backtrace.h.


Added:
    trunk/libjava/sysdep/arm/backtrace.h
      - copied unchanged from r128085,
branches/gcj/gcj-eabi-branch/libjava/sysdep/arm/backtrace.h
Modified:
    trunk/libjava/Makefile.am
    trunk/libjava/Makefile.in
    trunk/libjava/configure
    trunk/libjava/configure.ac
    trunk/libjava/configure.host
    trunk/libjava/exception.cc
    trunk/libjava/gcj/Makefile.in
    trunk/libjava/gnu/classpath/natVMStackWalker.cc
    trunk/libjava/include/Makefile.in
    trunk/libjava/libgcj.spec.in
    trunk/libjava/stacktrace.cc
    trunk/libjava/testsuite/Makefile.in
    trunk/libjava/testsuite/lib/libjava.exp
    trunk/libjava/testsuite/libjava.jni/jni.exp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908