-
Bug
-
Resolution: Won't Fix
-
P3
-
None
-
None
A DESCRIPTION OF THE REQUEST :
Basically, if a MessageDigest instance is updated simultaneously from 2 different threads, it throws this exception:
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:127)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:109)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:564)
at java.security.MessageDigest.update(MessageDigest.java:291)
at Go$1.run(Go.java:11)
at java.lang.Thread.run(Thread.java:722)
This is a feature request to make it more clear what is happening when developers run into this.
JUSTIFICATION :
Today's backtrace makes it seem like the internal JVM has been corrupted (which it has) but don't mention what the problem might be.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either make it threadsafe, or throw an exception (or more descriptive exception class?) when it is used in an unthreadsafe manner. Even adding to the message " this might be caused by thread unsafe usage " would be helpful.
ACTUAL -
It throws
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:127)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:109)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:564)
at java.security.MessageDigest.update(MessageDigest.java:291)
at Go$1.run(Go.java:11)
at java.lang.Thread.run(Thread.java:722)
---------- BEGIN SOURCE ----------
import java.security.MessageDigest;
class Go {
public static void main(String[] args) throws java.security.NoSuchAlgorithmException {
final MessageDigest md = MessageDigest.getInstance( " MD5 " );
for(int x = 0; x < 200; x++) {
new Thread(new Runnable() {
@Override
public void run() {
for(int y = 0; y < 1000; y++) {
md.update((byte)33);
}
}
}).start();
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
avoid using it in non threadsafe way.
Basically, if a MessageDigest instance is updated simultaneously from 2 different threads, it throws this exception:
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:127)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:109)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:564)
at java.security.MessageDigest.update(MessageDigest.java:291)
at Go$1.run(Go.java:11)
at java.lang.Thread.run(Thread.java:722)
This is a feature request to make it more clear what is happening when developers run into this.
JUSTIFICATION :
Today's backtrace makes it seem like the internal JVM has been corrupted (which it has) but don't mention what the problem might be.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Either make it threadsafe, or throw an exception (or more descriptive exception class?) when it is used in an unthreadsafe manner. Even adding to the message " this might be caused by thread unsafe usage " would be helpful.
ACTUAL -
It throws
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:127)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:109)
at java.security.MessageDigest$Delegate.engineUpdate(MessageDigest.java:564)
at java.security.MessageDigest.update(MessageDigest.java:291)
at Go$1.run(Go.java:11)
at java.lang.Thread.run(Thread.java:722)
---------- BEGIN SOURCE ----------
import java.security.MessageDigest;
class Go {
public static void main(String[] args) throws java.security.NoSuchAlgorithmException {
final MessageDigest md = MessageDigest.getInstance( " MD5 " );
for(int x = 0; x < 200; x++) {
new Thread(new Runnable() {
@Override
public void run() {
for(int y = 0; y < 1000; y++) {
md.update((byte)33);
}
}
}).start();
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
avoid using it in non threadsafe way.