Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=NJcs1ImNMb2WYufuR3nGV+jdhJO5BLD2iNj+lAteXRwo83jCsxPDjATfA9JP65/B/U/LYx6R+Drf1wniFmerBHxZTZ5ixUhG0qbHUFs+LA2N0Ably8qTVNFE//+suOHuBZ8ykZOxOGNavqLED+JDU+VGnMdGR/5dJOvi/aJ/Pfg=
Message-ID: <4625DAC3.2020808@gmail.com>
Date: Wed, 18 Apr 2007 09:45:55 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [jira] Commented: (HARMONY-2669) [classlib][charsets] Working
 with charset ISO-2022-CN crashes DRLVM
References: <10508951.1176826935858.JavaMail.jira@brutus>
 <200704172223.22850.gshimansky@gmail.com> <46252D7A.10807@gmail.com>
 <200704180132.29856.gshimansky@gmail.com>
In-Reply-To: <200704180132.29856.gshimansky@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Gregory Shimansky wrote:
> On Wednesday 18 April 2007 00:26 Tim Ellison wrote:
>> Gregory Shimansky wrote:
>>> Below is my evaluation of the bug HARMONY-2669. I think it is in ICU4JNI
>>> native code. The possible solution for it is to recompile ICUInterface34
>>> libraries from patched sources and file a bug on ICU meanwhile.
>>>
>>> I would like to know, what sources were used to compile ICU4JNI for
>>> windows and other operation systems? I found today that ICU4JNI 3.4
>>> contains quite a lot of memory leaks, and there is a patch to fix them in
>>> v3.4 [1]. Was it used to compile our binaries (from what I learned while
>>> analyzing this bug on windows 32 it *was* used)? I know that I didn't use
>>> it when I compiled ICU for IPF because I learned about its existence only
>>> today. Are there any other patches for ICU code that we need to use for
>>> version 3.4?
>>>
>>> [1]
>>> ftp://ftp.software.ibm.com/software/globalization/icu/icu4j/icu4jni/3.4/i
>>> cu4jni_3_4_patch-01.zip
>> Sorry that you had to find it the hard way Gregory.  The ICU4JNI code
>> does have the patch applied, as described in the readme in the depends'
>> ICU4JNI directory[1].
> 
> I didn't find it a hard way, I just didn't look for any patches when I created 
> IPF binaries some time ago. I the memory leaks patch when I went to ICU site 
> to download its sources to see what's going on when it calls VM JNI code. 
> What I found out is that it calls VM JNI code with a wrong elems pointer and 
> to fix the bug we need to patch ICU. The bug is present it 3.6 as well.
> 
> So my question was actually, do we need any patches other than memory leaks 
> patch to build ICU binaries that we have in SVN currently?

No, the code is just 3.4 with patch 1.

I'd have no objection to moving to 3.6, and asking the ICU team for an
official patch for the elems bug.  We could use a temporary patch while
we wait.

Regards,
Tim