This looks like it could be a valid problem, but I do not see any ColorModel/CMM
JCK failures on windows-ia64 (hopper b16). Please update the bug report with
a list of JCK tests for which you see CMM related failures.
Carlos.Lucasius@Canada (July 9, 2002):
Licensee (Appeal Virtual Machines, now BEA) has indicated that they will
send a test case a.s.a.p.:
> we didn't have these problems at first either (with that build)
> however some changes in JRockit apparently made us execute other
> parts of the cmm.dll. Please let me get back to you with a re-
> producable testcase. I'm travelling so it might take a couple
> of days. Sorry for the delay.
Carlos.Lucasius@Canada (August 1, 2002):
Licensee (Appeal Virtual Machines, now BEA) sent the following update:
> We are not always able to reproduce the problem it only happens
> sometimes unfortunately. The easiest way we know of is if you run
> our JVM together with your libraries. I think you can download the
> beta of our JVM from our web-site and then replace your jvm.dll
> with our jvm.dll.
> Padding the arrays does make the problem go away, always.
> Sorry for not being able to provide a more reproducable testcase.
Carlos.Lucasius@Canada (September 16, 2003):
Received new feedback from Appeal/BEA (J2SE source licensee):
The problem can now be reproduced consistently, using 1.4.2b28 on
Windows Server 2003 EE, Itanium2 (1CPU, 900MHz). It may be necessary
to submit an escalation against this issue so this bug will be fixed
in a future 1.4.2 update release. If this bug can be confirmed to
also exist in 1.5, it will probably need to be fixed there as well.
Please see suggested fix in the bug description. Please consider
changing priority of this bug to a higher level -- I'd suggest P2.
I believe the problem may be due to an MS specific #pragma statement in
#if defined (KPWIN32)
#pragma pack(push, SpLevel, 4)
It appears (from looking at kcmsos.h) that KPWIN32 is defined for IA64, so this
pragma will be activated on windows-ia64 builds. The pack pragma will muck with
the preferred alignment of structure fields, so setting this value to 4 on
IA64 is dangerous since natural alignment of pointers must be maintained (i.e.
pointers must sit on 8-byte aligned boundaries). If my evaluation is accurate,
this would explain why manually padding the struct definitions in that one
header file fixes the problem for the submitter.
I propose we conditionally disable this pragma on windows-ia64:
#if defined (KPWIN32) && !defined (_M_IA64)
Note that this pragma occurs twice in the file (once for push, once for pop).
I have not yet tried this fix in a windows-ia64, but will attempt to do so
shortly. Since I've still not been able to reproduce this failure on
a Win64 machine, and the submitter is able to reproduce it easily, it would be
very helpful if the submitter could apply this new suggested fix to their
workspace to see if it solves the problem.