harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass
Date Fri, 27 Oct 2006 10:43:17 GMT
Gregory Shimansky wrote:
>> But on Linux these tests fail with
>> lost of different exceptions:
>> For java.lang.ClassGenericsTest:
>> java.lang.ClassNotFoundException: java.lang.ClassGenericsTest$Mc009^Z^Z^Z
>> java.lang.NoClassDefFoundError: java/lang/ClassGenericsTest$Mc007^Z
>> java.lang.TypeNotPresentException: Type
>> java.lang.ClassGenericsTest$Mc009\0d5\0b6\0db\080\0db\0b1 not present
>> For java.lang.ClassGenericsTest4:
>> Some NPEs from unobvious sources. I've attached two test reports to
>> this email. Anyways, it looks like timeout is not the case for these
>> tests failures.
> Ok I think I've found the cause of problems with these two tests on
> Linux which I had yesterday. On Gentoo I have russian locale set
> "ru_RU.KOI8-R" while on all other Linux installations it appears there
> are various combinations of *.UTF-8 locales (usually "en_US.UTF-8", but
> I found "en_AU.UTF-8" on oner server).
> I experimented a bit with this stuff and found out that these tests work
> ok when locale is some sort of UTF-8 one, including ru_RU.UTF-8 one.
> The result of test run is actually affected by locale set at compilation
> time, not the one set at the subsequent test runs. When locale at
> compile time is set to *.UTF-8, then test run is successful on any
> locale set after it. If locale is set to something simple like "C" (!)
> or "ru_RU.KOI8-R" at compile time then test run fails no matter what
> locale is set when tests are running.
> I wonder what we should blame here, compiler, VM, classlib or the tests?

IMHO, the test is not correct for non-unicode configurations,
as some unicode-named classfiles cannot be saved with filename in locale-specified character

I think that fixing \uXXXX characters in these tests to some ASCII characters should
fix the problem (I haven't checked myself).

However, I do not know the original intention why those characters were put to
the class names in the first place, does anyone know an explanation?

View raw message