Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <24650741.1185287131379.JavaMail.jira@brutus>
Date: Tue, 24 Jul 2007 07:25:31 -0700 (PDT)
From: "Vasily Zakharov (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-4493) [classlib][EUT] jdtcoremodel suite
 is blocked because ClasspathTests.testEncoding cannot remove unicode dir
In-Reply-To: <11086531.1184802184686.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vasily Zakharov updated HARMONY-4493:
-------------------------------------

    Attachment: Test5.java

Here's even more precise reproducer, see Test5.java attached.

It does the following: checks if test directories exist, creates them if necessary, lists the directory contents and checks if listed subdirectory exists.

So, the test directories are created on the first test run and are not removed.

Running the test multiple times on RI and Harmony clearly shows that the result doesn't depend on whether the test directories were created on RI or on Harmony, but only depends on whether File.list() is called on RI or on Harmony.

Output on RI:

afterName length: 6
SUCCESS

On Harmony:

afterName length: 4
FAIL

Moreover, adding a control print to File.list() shows that the native method File.listImpl() for the test directory returns the byte array of length 4, which clearly can't be the right directory name (it should be 6 bytes long).

So, the problem is clearly located somewhere in File.listImpl() implementation located at working_classlib/modules/luni/src/main/native/luni/shared/file.c

Another potential problem, that's hidden by the problem above, is that listImpl() return is converted from bytes to String (see File.java, line 877) by a call to Util.toString() while probably Util.toUTF8String() should be used instead. This should be checked when the main problem in File.listImpl() is resolved.


> [classlib][EUT] jdtcoremodel suite is blocked because ClasspathTests.testEncoding cannot remove unicode dir
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-4493
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4493
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Ilya Berezhniuk
>            Priority: Blocker
>         Attachments: test2.class, test2.java, Test3.java, Test4.java, Test5.java
>
>
> Test org.eclipse.jdt.core.tests.model.ClasspathTests.testEncoding creates directory with unicode name in its project directory. Then it removes project, it involves removing underlying files and directories.
> When executing on DRLVM, it cannot remove unicode directory and therefore the whole project, and then tries 60 times with 1 second delay. So test goes 1 minute, and all remaining tests in ClasspathTests suite also execute 1 minute.
> Although debugging under Eclipse is now unstable on DRLVM/Linux (it often crashes with SIGSEGV when using single stepping), I've got some results using breakpoints.
> Looks like the problem is somewhere in enumerating subdirectories of project dir "P". Eclipse uses org.eclipse.core.internal.localstore.UnifiedTree to enumerate subitems in project folder: accept(IUnifiedTreeVisitor, int) calls addNodeChildrenToQueue to fill queue with subitems. But when queue is filled, it contains incorrect path to unicode directory. Directory is named "src\u3400", but queue item for this directory contains path from 6 to 8 chars and named as "srcXXXXX", where XXXXX can be various characters including space.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.