--- 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=14790&action=view)
Test case
Can you try running this test program in your setup? We should confirm first
that this isn't a regre
--- 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 #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 g
--- 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
--- 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 #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 #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 #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=11618&action=view)
Test case.
Test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27925
Severity: normal
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 #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
--- 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 #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
--- 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
--- 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 #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 #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
--- 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?
--
--- 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 #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 #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 InvalidAlgorithmParameterE
--- 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 #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 #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 #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 #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 #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=11246&action=view)
SecureRandom setSeed test
I'm testing a patch for this.
Note that the attached test case will repeatedly out
--- 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
--- 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: 6
--- 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.
--
es to 'this' from an
enclosing class
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: csm
widely
Product: gcc
Version: 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 d
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
dot org
GC
32 matches
Mail list logo
