Re: libgcj/6311: BigInteger Constructor Creates False Results (crypto failures?).

Re: libgcj/6311: BigInteger Constructor Creates False Results (crypto failures?).

[tromey]

Synopsis: BigInteger Constructor Creates False Results (crypto failures?).

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Mon Apr 15 14:12:26 2002
Responsible-Changed-Why:
    I'm handling this.
State-Changed-From-To: open->closed
State-Changed-By: tromey
State-Changed-When: Mon Apr 15 14:12:26 2002
State-Changed-Why:
    I tried this with the current 3.1 branch gcj.
    It worked fine.  I'm closing this PR since I think it is fixed.
    FYI, gcj 3.1 will be out fairly soon.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6311

libgcj/6311: BigInteger Constructor Creates False Results (crypto failures?).

[ray]

>Number:         6311
>Category:       libgcj
>Synopsis:       BigInteger Constructor Creates False Results (crypto failures?).
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 15 10:16:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Ray Whitmer
>Release:        3.0.4
>Organization:
>Environment:
Installing 3.x gcc tools including gcj from the Mandrake 8.2 release installation disk
>Description:
Java.math.BigInteger has a constructor which accepts a byte array.  By getting the byte array, this makes it possible to easily construct a BigInteger which has the same value.  In the libgcj implementation, some byte arrays produce the wrong big integer.  Attached is a very short test program that demonstrates the problem.  If run in a sun java implementation, the BigInteger constructed from the byteArray is correct.  But if run against libgcj, the BigInteger constructed from the byte array is 0 instead of the correct value.
This could cause Java cryptographic methods to fail.  It only fails on certain numbers.

I haven't looked at the source to determine the cause of the failure.
>How-To-Repeat:
This is simple enough and my gcj build is recent enough (and I produced it on prior builds, but didn't know exactly what caused the problem since it was a large functioning program under a Sun JVM.

The compilation is very straitforward:

gcj --main=BigIntBug -o BigIntBug BigIntBug.java
or on the JVM
javac BigIntBug.java

If I now run BigIntBug, I get:

./BigIntBug
The value is 8483895
Byte 0 is 0
Byte 1 is -127
Byte 2 is 116
Byte 3 is 55
After creating from its own internal array, the value is 0

Notice that a 0 is produced.

If running under a jvm, I get the following:
java -cp . BigIntBug
The value is 8483895
Byte 0 is 0
Byte 1 is -127
Byte 2 is 116
Byte 3 is 55
After creating from its own internal array, the value is 8483895
Notice that the correct result is produced.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="BigIntBug.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="BigIntBug.java"

aW1wb3J0IGphdmEubWF0aC5CaWdJbnRlZ2VyOwogIApwdWJsaWMgY2xhc3MgQmlnSW50QnVnIHsK
ICBwdWJsaWMgc3RhdGljIHZvaWQgbWFpbihTdHJpbmdbXSBhcmdzKQogIHsKICAgIEJpZ0ludGVn
ZXIgbnVtYmVyID0gbmV3IEJpZ0ludGVnZXIoIjg0ODM4OTUiKTsKICAgIFN5c3RlbS5vdXQucHJp
bnRsbigiVGhlIHZhbHVlIGlzICIgKyBudW1iZXIpOwogICAgYnl0ZVtdIGFycmF5ID0gbnVtYmVy
LnRvQnl0ZUFycmF5KCk7CiAgICBmb3IgKGludCBpID0gMDsgaSA8IGFycmF5Lmxlbmd0aDsgaSsr
KQogICAgICBTeXN0ZW0ub3V0LnByaW50bG4oIkJ5dGUgIiArIGkgKyAiIGlzICIgKyBhcnJheVtp
XSk7CiAgICBCaWdJbnRlZ2VyIGJ1ZyA9IG5ldyBCaWdJbnRlZ2VyKDEsYXJyYXkpOwogICAgU3lz
dGVtLm91dC5wcmludGxuKCJBZnRlciBjcmVhdGluZyBmcm9tIGl0cyBvd24gaW50ZXJuYWwgYXJy
YXksIHRoZSB2YWx1ZSBpcyAiICsgYnVnKTsKICB9Cn0K