--- Comment #5 from csm at gnu dot org 2006-04-11 04:21 ---
The original issue seems to be fixed; on gcj version `gcj (GCC) 4.2.0 20060410
(experimental)' I get this output from the `seed' testcase:
Byte difference in a seeded PRNG: 64
Seed data
--- Comment #7 from csm at gnu dot org 2006-04-11 20:58 ---
I'm not sure I understand your situation. Are you doing:
SecureRandom r = new SecureRandom ();
for (...)
r.getBytes (...); // produces the same bytes each time
Or
for (...)
{
SecureRandom r = new
--- Comment #9 from csm at gnu dot org 2006-04-12 04:46 ---
Created an attachment (id=11246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11246action=view)
SecureRandom setSeed test
I'm testing a patch for this.
Note that the attached test case will repeatedly output the same
--- Comment #11 from csm at gnu dot org 2006-04-12 18:19 ---
Fixed for message digest-based PRNGs.
--
csm at gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from csm at gnu dot org 2006-04-12 20:17 ---
*** This bug has been marked as a duplicate of 24642 ***
--
csm at gnu dot org changed:
What|Removed |Added
--- Comment #3 from csm at gnu dot org 2006-04-12 20:17 ---
*** Bug 27111 has been marked as a duplicate of this bug. ***
--
csm at gnu dot org changed:
What|Removed |Added
--- Comment #4 from csm at gnu dot org 2006-04-12 20:18 ---
Testing a patch.
--
csm at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #6 from csm at gnu dot org 2006-04-14 20:01 ---
Fixed in CVS.
--
csm at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from csm at gnu dot org 2006-04-21 02:30 ---
There's an `instanceof' check that I think is wrong in
gnu.javax.crypto.jce.sig.DHKeyPairGeneratorSpi.java, line 80:
- if (! (params instanceof DHGenParameterSpec))
- throw new InvalidAlgorithmParameterException(params
--- Comment #7 from csm at gnu dot org 2006-04-21 06:37 ---
GnuDHKeyPairGenerator looks all-over wrong when you give it a DHParameterSpec.
It is generating an entirely new P and G, even when you explicitly set those
values. This is totally bogus; if you already have DH parameters, you
--- Comment #10 from csm at gnu dot org 2006-04-22 19:26 ---
I don't know; a confusing internal structure doesn't impact anyone trying to
use Classpath with their application, they'll just want their program to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
--- Comment #3 from csm at gnu dot org 2006-05-01 06:41 ---
It looks like methods internal to Class need to bypass the security manager
when getting the class loader, or should be doing that lookup in a
`doPriviliged' block, right?
Does Classpath itself suffer from this?
--
http
--- 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
--- 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
--- 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
--- 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
--- 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=11613action=view)
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
--- 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
--- 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
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csm at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27925
--- Comment #1 from csm at gnu dot org 2006-06-07 00:42 ---
Created an attachment (id=11618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11618action=view)
Test case.
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27925
--- 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
--- Comment #6 from csm at gnu dot org 2006-06-07 02:52 ---
*** Bug 27908 has been marked as a duplicate of this bug. ***
--
csm at gnu dot org changed:
What|Removed |Added
--- 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
--- Comment #12 from csm at gnu dot org 2006-07-22 05:23 ---
Subject: Re: java.security.InvalidAlgorithmParameterException
On Jul 21, 2006, at 5:31 PM, raif at swiftdsl dot com dot au wrote:
--- Comment #11 from raif at swiftdsl dot com dot au
2006-07-22 00:31 ---
any
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csm at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
GCC build triplet: i686-pc-linux-gnu
GCC host
: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csm at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csm at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
--- Additional Comments From csm at gnu dot org 2005-09-08 05:49 ---
Confirmed. The doFinal methods should leave 'state' as-is, as the reporter
suggests. It is up to CipherSpi
subclasses to reset themselves when their 'engineDoFinal' methods are called.
--
What|Removed
--- Comment #1 from csm at gnu dot org 2007-12-17 23:27 ---
Jessie is not using NIO. At least, it shouldn't be. Something is calling
'getChannel' on an SSLSocket, which doesn't make sense (you cannot use SSL that
way).
The JDK returns 'null' if you call getChannel on an SSLSocket
--- Comment #1 from csm at gnu dot org 2007-12-18 17:45 ---
A CloneNotSupportedException is not a null pointer exception.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
--- Comment #2 from csm at gnu dot org 2007-12-18 18:08 ---
Created an attachment (id=14790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14790action=view)
Test case
Can you try running this test program in your setup? We should confirm first
that this isn't a regression in GCJ
32 matches
Mail list logo
