Do we really have a problem? Or is it something else?
Last night, Gregory tested his fix, and I've build snapshots (r486417)
on x86 linux/win and x86_64 linux and spot checked with apps and such,
and things seem to work.
I'n posting the snapshots now to ~geirm and will send a separate note
for people to evaluate.
geir
Stepan Mishura wrote:
On 12/13/06, Geir Magnusson Jr. wrote:
Grrr. We had a thread last night "DRLVM broken on em64t" that you
should read.
Sorry, I hadn't read the discussion when I wrote about regression.
In the end, what I was asking is if/how the behavior of
GetSystemProperty() changed with our update to the property management
inside of DRLVM, and the ramifications of that.
Looking at Ollie's change in r486100, he seems to think that it's not an
error to not have the property set, but our impl of GetSystemProperty it
is.
That's the issue I'm trying to get to - does the API of
GetSystemProperty() specify that it returns an error code if the
property isn't set?
If so, then Ollie's code is wrong. If not, then it's either that the
API is ambiguous (Ollie's assumption wasn't unreasonable) or our impl of
GetSystemProperty() is wrong.
It seems like in either case, we have a big problem still?
Well, if there is no quick fix I would roll back the change to make CC
happy.
Thanks,
Stepan.
geir
Stepan Mishura wrote:
> Gregory and Oliver,
>
> Could you have a look on your update to luniglob.c? It causes classlib
test
> failures on DRL VM. So if I rollback your update all classlib test pass
for
> me.
>
> Index: modules/luni/src/main/native/luni/shared/luniglob.c
> ===================================================================
> --- modules/luni/src/main/native/luni/shared/luniglob.c (revision
486504)
> +++ modules/luni/src/main/native/luni/shared/luniglob.c (working copy)
> @@ -268,16 +268,8 @@
> unsigned i = 0;
> /* Make a string version of the CP separator */
> char cpSeparator[] = {(char)hysysinfo_get_classpathSeparator
(),
> '\0'};
> -
> - /* Read current value of bootclasspath property */
> - rcGetProperty = (*vmInterface)->GetSystemProperty
(vmInterface,
> - BOOTCLASSPATH_PROPERTY,
> - &bootstrapClassPath);
> + bootstrapClassPath = "";
>
> - /* Gregory - no property is found, VM bootclasspath is not
defined
> */
> - if (VMI_ERROR_NONE != rcGetProperty)
> - bootstrapClassPath = NULL;
> -
> qsort(props, number, sizeof(key_value_pair), props_compare);
>
> for (;i < number; i++)
>
> Thanks,
> Stepan.
>
> On 12/13/06, Stepan Mishura wrote:
>
>> On 12/13/06, Vladimir Ivanov wrote:
>> >
>> > CC is failed to run classlib tests over the DRLVM won windows and
linux
>> > with
>> > messages:
>> >
>> > Unit Test Error Details: (581) Test: testGetAccessibleAction
>> > Class:
>> > java.awt.AccessibleAWTCheckboxMenuItemTest
>> > java.lang.NoClassDefFoundError: javax/accessibility/Accessible
Test:
>> > testGetAccessibleRole Class:
>> java.awt.AccessibleAWTCheckboxMenuItemTest
>> > java.lang.NoClassDefFoundError : javax/accessibility/Accessible
>> > Could somebody reproduce it?
>>
>>
>> I can reproduce it. It seems that a cause is update for
>> bootstrapClassPath
>> in modules/luni/src/main/native/luni/shared/luniglob.c
(r486100-486378).
>>
>> I've rolled back them localy and this resolved classlib tests failures
on
>> DRL VM.
>>
>> Thanks,
>> Stepan
>>
>
>
>
