JDK-8263004 : SPARC CodeBuffer overflow in generate_satb_log_enqueue
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11.0.10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc_64
  • Submitted: 2021-03-04
  • Updated: 2021-09-24
  • Resolved: 2021-03-10
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 11
11.0.12-oracle b01Fixed
Related Reports
Relates :  
JDK-8166317 - InterpreterCodeSize should be computed
Description
The hard-coded size for the CodeBuffer used in generate_satb_log_enqueue is too small; we can overrun the buffer under certain rare conditions. Specifically, we have seen a case where CBCond was not supported (older Fujitsu hardware) and libjvm.so was loaded far enough away from the code cache that PC-relative addressing could not be used. This case resulted in an overrun of 8 bytes (2 instructions).

The fix for JDK-8166317 appears to have been the "straw that broke the camel's back". The with_frame version of satb_log_enqueue is a few instructions longer than the frameless version, making this issue a regression in practice.
Comments
The seemingly obvious fix is to simply double EnqueueCodeSize, making it 256 bytes (and remove the *2 when we create the CodeBuffer in generate_dirty_card_log_enqueue).
10-03-2021
Here is an example taken from a core file where cbcond was disabled (not supported by hardware) and libjvm.so was loaded very far away: (dbx) dis 0xffffffff68405800, 0xffffffff68405888 0xffffffff68405800: save %sp, -176, %sp 0xffffffff68405804: ldx [%g2 + 56], %l0 0xffffffff68405808: cmp %l0, %g0 0xffffffff6840580c: be,pn %xcc,0xffffffff6840582c ! 0xffffffff6840582c 0xffffffff68405810: nop 0xffffffff68405814: ldx [%g2 + 72], %l1 0xffffffff68405818: dec 8, %l0 0xffffffff6840581c: stx %i0, [%l1 + %l0] 0xffffffff68405820: stx %l0, [%g2 + 56] 0xffffffff68405824: ret 0xffffffff68405828: restore 0xffffffff6840582c: mov %g1, %l0 0xffffffff68405830: mov %g3, %l1 0xffffffff68405834: mov %g4, %l2 0xffffffff68405838: mov %o0, %l3 0xffffffff6840583c: mov %o7, %l4 0xffffffff68405840: mov %g2, %o0 0xffffffff68405844: mov %g2, %l5 0xffffffff68405848: sethi %hi(0x7c00), %o7 0xffffffff6840584c: bset 0x00000000000003ff, %o7 ! 0x7fff 0xffffffff68405850: sllx %o7, 12, %o7 0xffffffff68405854: bset 4017, %o7 0xffffffff68405858: sllx %o7, 10, %o7 0xffffffff6840585c: bset 16, %o7 0xffffffff68405860: sllx %o7, 10, %o7 0xffffffff68405864: call %o7 + 112 0xffffffff68405868: nop 0xffffffff6840586c: mov %l5, %g2 0xffffffff68405870: mov %l0, %g1 0xffffffff68405874: mov %l1, %g3 0xffffffff68405878: mov %l2, %g4 0xffffffff6840587c: mov %l3, %o0 0xffffffff68405880: ba,pt %icc,0xffffffff68405804 ! 0xffffffff68405804 0xffffffff68405884: mov %l4, %o7 0xffffffff68405888: illtrap 0x0 Notice the setup needed for the call into handle_zero_index_for_thread (libjvm.so) at 0xffffffff68405864.
10-03-2021