--- 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 to be
--- 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 #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
--- 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
