On Thu, 23 Jul 2026 17:46:32 GMT, Ekaterina Pavlova <[email protected]> wrote:
> Why the test fails only in container/docker environment? Why no failures in > jdk CI? What I understand is It's not container-specific… the CPU_SHA check is guarded to x86 and has nothing to do with containers It's a test-vs-build revision mismatch. The expected value was set to 31 in JDK-8383881 and changed to 33 in JDK-8384869 two weeks later (2026-05-28) The ATR workspace I ran from still had the pre-8384869 test source, while the pinned build (jdk-27+25) reported CPU_SHA = 33 hence "Expected 31. Obtained 33". The test at tag jdk-27+25 already expects 33, so a from-source build of that tag passes; this only shows up when a prebuilt JDK is paired with a separately synced test workspace Since the value has needed updating twice in two weeks, this PR drops the exact-value assertion and just checks the constant is present, which I think is all checkForTruncation needs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32017#issuecomment-5061849214
