JDK-8335238 : multiple hotspot jtreg tests hang due to the sigbus error on x86 linux (Ubuntu i386) after JDK-8320886
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 23,24
  • Priority: P2
  • Status: Open
  • Resolution: Unresolved
  • OS: linux
  • CPU: x86
  • Submitted: 2024-06-27
  • Updated: 2024-07-22
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 23 JDK 24
23Unresolved 24Unresolved
Related Reports
Relates :  
JDK-8320886 - Unsafe_SetMemory0 is not guarded
Description
This bug was found in Ubuntu oracular. 24.04 Noble is also affected.

A number of tests hang indefinitely. The bug is reproduced reliably with runtime/Unsafe/InternalErrorTest.java

make test TEST=runtime/Unsafe/InternalErrorTest.java CONF=linux-x86-server-release

The test hangs indefinitely. Same occurs in the fastdebug configuration.

When attaching with gdb the following stack trace is present:

Thread 2 "MainThread" received signal SIGBUS, Bus error.
[Switching to Thread 0x9e1afb40 (LWP 2708183)]
0xef88efa0 in memset (__len=<optimized out>, __ch=240, __dest=<optimized out>) at /usr/include/i386-linux-gnu/bits/string_fortified.h:59
59	  return __builtin___memset_chk (__dest, __ch, __len,
(gdb) where
#0  0xef88efa0 in memset (__len=<optimized out>, __ch=240, __dest=<optimized out>) at /usr/include/i386-linux-gnu/bits/string_fortified.h:59
#1  Copy::pd_fill_to_bytes (value=240 '\360', count=<optimized out>, to=<optimized out>) at src/hotspot/cpu/x86/copy_x86.hpp:51
#2  Copy::fill_to_bytes (value=240 '\360', count=<optimized out>, to=<optimized out>) at src/hotspot/share/utilities/copy.hpp:278
#3  Copy::fill_to_memory_atomic (to=<optimized out>, size=<optimized out>, value=<optimized out>) at src/hotspot/share/utilities/copy.cpp:255
#4  0xf004a742 in Unsafe_SetMemory0 (env=<optimized out>, unsafe=<optimized out>, obj=<optimized out>, offset=<optimized out>, size=<optimized out>, value=<optimized out>)
    at src/hotspot/share/prims/unsafe.cpp:395
#5  0xe74f1308 in ?? ()
#6  0xe74eda6a in ?? ()
#7  0xe74eda6a in ?? ()
#8  0xe74eda6a in ?? ()
#9  0xe74eda6a in ?? ()
#10 0xe74edf56 in ?? ()
#11 0xe74eda6a in ?? ()
#12 0xe74eda6a in ?? ()
#13 0xe74eda6a in ?? ()
#14 0xe74edba0 in ?? ()
#15 0xe74edba0 in ?? ()
#16 0xe74edba0 in ?? ()
#17 0xe74edf56 in ?? ()
#18 0xe74edba0 in ?? ()
#19 0xe74ede20 in ?? ()
#20 0xe74eda6a in ?? ()
#21 0xe74e6c7c in ?? ()
#22 0xefaaef72 in JavaCalls::call_helper (result=0x9e1af298, method=..., args=0x9e1af1f8, __the_thread__=0x9cf16b90) at src/hotspot/share/runtime/javaCalls.cpp:415
#23 0xefaafb55 in JavaCalls::call (__the_thread__=0x9cf16b90, args=0x9e1af1f8, method=..., result=0x9e1af298) at src/hotspot/share/runtime/javaCalls.cpp:329
#24 JavaCalls::call_virtual (__the_thread__=0x9cf16b90, args=0x9e1af1f8, signature=0x9f2a1a48, name=0x9f29f068, spec_klass=0x9ef97c68, result=0x9e1af298)
    at src/hotspot/share/runtime/javaCalls.cpp:185
#25 JavaCalls::call_virtual (result=0x9e1af298, receiver=..., spec_klass=0x9ef97c68, name=0x9f29f068, signature=0x9f2a1a48, __the_thread__=0x9cf16b90)
    at src/hotspot/share/runtime/javaCalls.cpp:191
#26 0xefb913f9 in thread_entry (thread=0x9cf16b90, __the_thread__=0x9cf16b90) at src/hotspot/share/prims/jvm.cpp:2937
#27 0xefac78e8 in JavaThread::thread_main_inner (this=0x9cf16b90) at src/hotspot/share/runtime/javaThread.hpp:536
#28 0xf0017cf3 in Thread::call_run (this=0x9cf16b90) at src/hotspot/share/runtime/thread.cpp:221
#29 0xefe04505 in thread_native_entry (thread=0x9cf16b90) at src/hotspot/os/linux/os_linux.cpp:864
#30 0xf04e8fe7 in ?? () from /lib/i386-linux-gnu/libc.so.6
#31 0xf05805a8 in ?? () from /lib/i386-linux-gnu/libc.so.6
Comments
Since this appears to be a Linux/x86 only issue, I'll unassigned myself again, so maintainers of that platform can pick this up. As I said above, I think the easiest fix here is to implement StubRoutines::_unsafe_setmemory. A simple implementation could just call Copy::fill_memory_atomic, but with an explicit UnsafeMemoryAccessMark which sets the error continuation pc to after the call to fill_memory_atomic.
05-07-2024
This appears to be a 32-bit Linux issue? Note that Linux x64 doesn't use `fill_to_memory_atomic`. FWIW, the UnsafeSetMemory_stub that's used on x64 sets a custom continuation PC for the signal handler, but the non-stub version that uses 'fill_to_memory_atomic' will just pick the next instruction, which is apparently wrong in this case. Easiest way to fix this is probably to implement JDK-8329331 on x86_32 as well, since the stub will have a more accurate continuation PC.
02-07-2024
ILW=HHL=P2
02-07-2024
it appears that the signal handler returns an address that contains a jump just before the offending instruction `rep stos %eax,%es:(%edi)` causing an infinite loop.
01-07-2024