From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18997 invoked by alias); 15 Apr 2002 17:16:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 18950 invoked by uid 71); 15 Apr 2002 17:16:01 -0000 Resent-Date: 15 Apr 2002 17:16:01 -0000 Resent-Message-ID: <20020415171601.18949.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org, java-prs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, ray@xmission.com Received:(qmail 13812 invoked by uid 61); 15 Apr 2002 17:07:52 -0000 Message-Id:<20020415170752.13811.qmail@sources.redhat.com> Date: Mon, 15 Apr 2002 10:16:00 -0000 From: ray@xmission.com Reply-To: ray@xmission.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version:gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: libgcj/6311: BigInteger Constructor Creates False Results (crypto failures?). X-SW-Source: 2002-04/txt/msg00781.txt.bz2 List-Id: >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