JDK-8254042 : gtest/GTestWrapper.java failed os.test_random
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64,aarch64
  • Submitted: 2020-10-05
  • Updated: 2024-12-20
  • Resolved: 2020-11-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b27Fixed
Related Reports
Duplicate :  
JDK-8254810 - gtest for os::random() fails on windows x64
Relates :  
JDK-8254810 - gtest for os::random() fails on windows x64
Description
The following test failed in the JDK16 CI:

gtest/GTestWrapper.java

Here's a snippet from the log file:

[----------] 11 tests from os
[ RUN      ] os.page_size_for_region_vm
[       OK ] os.page_size_for_region_vm (0 ms)
[ RUN      ] os.page_size_for_region_aligned_vm
[       OK ] os.page_size_for_region_aligned_vm (0 ms)
[ RUN      ] os.page_size_for_region_alignment_vm
[       OK ] os.page_size_for_region_alignment_vm (0 ms)
[ RUN      ] os.page_size_for_region_unaligned_vm
[       OK ] os.page_size_for_region_unaligned_vm (0 ms)
[ RUN      ] os.test_random
/opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S103/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a771f71b-fe39-4079-a04b-b91e83b3cffe/runs/f418d221-5388-4ed7-9121-c986a94b04ae/workspace/open/test/hotspot/gtest/runtime/test_os.cpp:134: Failure
Expected equality of these values:
  num
    Which is: 1589873406
  1043618065
bad seed
[  FAILED  ] os.test_random (0 ms)
[ RUN      ] os.page_size_for_region_with_zero_min_pages_vm_assert
[       OK ] os.page_size_for_region_with_zero_min_pages_vm_assert (269 ms)
[ RUN      ] os.test_print_hex_dump_vm
[       OK ] os.test_print_hex_dump_vm (6 ms)
[ RUN      ] os.vsnprintf_vm
[       OK ] os.vsnprintf_vm (0 ms)
[ RUN      ] os.snprintf_vm
[       OK ] os.snprintf_vm (0 ms)
[ RUN      ] os.jio_vsnprintf_vm
[       OK ] os.jio_vsnprintf_vm (0 ms)
[ RUN      ] os.jio_snprintf_vm
[       OK ] os.jio_snprintf_vm (0 ms)
[----------] 11 tests from os (275 ms total)
Comments
Changeset: 4db05e99 Author: Coleen Phillimore <coleenp@openjdk.org> Date: 2020-11-30 12:48:17 +0000 URL: https://git.openjdk.java.net/jdk/commit/4db05e99
30-11-2020
This test calls init_random() where it's not thread safe. os::random updates the _rand_seed with the next random value. void os::init_random(unsigned int initval) { _rand_seed = initval; } The os random test, does: os::init_random(seed); int num; for (int k = 0; k < reps; k++) { num = os::random(); double u = (double)num / m; ASSERT_TRUE(u >= 0.0 && u <= 1.0) << "bad random number!"; // calculate mean and variance of the random sequence mean += u; variance += (u*u); } mean /= reps; variance /= (reps - 1); ASSERT_EQ(num, 1043618065) << "bad seed"; ... So if any other thread calls os::init_random() or os::random() during this loop, the 'num' number will come out wrong. This test is defined like this: TEST(os, test_random) { So I don't know why any other thread could be calling os::random() or os::init_random(). Update: there are other VM threads running during this test. Any one of these could call os::random and messing up this test.
24-11-2020
ILW = HLM = P3
06-10-2020