On Fri, 13 Sep 2024 16:12:59 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
> > After switching to a Hotspot Mutex, it looks like the `windows-x64 / test > > (hs/tier1 common) GHA` is failing because the test `release_bad_ranges` in > > test_os.cpp is expecting an assertion and an error message to be printed. > > However, when this printing happens, `tty_lock` gets acquired out of rank > > order with the already held `NMT_lock`, causing the lock rank assertion > > fail. One solution would be to lower the rank of `tty_lock`. I'm not sure > > that's the best solution because that might cause rank conflicts with other > > locks (and it makes sense to give locks the highest possible rank to > > minimize future conflicts). > > What code exactly locks tty_lock? This is weird. We print the error in this case via print_error_for_unit_test(), which takes care only to use raw fprintf(stderr) for this very reason... therefore I am interested in understanding the lock semantics, to know if deadlock detection found a real problem or if this is just a weird error setup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2349320770
