From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28853 invoked by alias); 16 Jun 2011 20:52:24 -0000 Received: (qmail 28830 invoked by uid 22791); 16 Jun 2011 20:52:24 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_UF X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Jun 2011 20:52:12 +0000 From: "ro at CeBiTec dot Uni-Bielefeld.DE" To: java-prs@gcc.gnu.org Subject: [Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcj X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Thu, 16 Jun 2011 20:52:00 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2011-q2/txt/msg00063.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-16 20:51:00 UTC --- > It has been a while, but I think either _Jv_NewStringUTF > or _Jv_NewStringUtf8Const. IIRC one of these is run > during class initialization to turn string constants into > String objects. Thanks. It turned out those were ok. When I logged calls to JvNewByteArray, I found two: JvNewByteArray: length = 1 JvNewByteArray: length = 0 The first one is as expected for "a", the second seems fishy: at the end of java::lang::String::getBytes, bufpos was 0 and buflen 1, so a new empty buffer was returned. Looking further, this is a problem with iconv somehow: in gnu::gcj::convert::Output_iconv::write, iconv_adapter returns -1 with errno == EILSEQ. Not understanding this iconv business at all, I have no idea how this can happen. Rainer