United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6567360 SIGBUS in jvmti RawMonitor magic check for unaligned bad monitor pointer
JDK-6567360 : SIGBUS in jvmti RawMonitor magic check for unaligned bad monitor pointer

Details
Type:
Bug
Submit Date:
2007-06-08
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic,solaris_10
Sub-Component:
jvmti
CPU:
sparc,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0u34,6u2,7
Fixed Versions:
hs15 (b03)

Related Reports
Backport:
Backport:

Sub Tasks

Description
The following nsk/jvmti tests failed with SIGBUS once in nightly (2007.06.02):
  nsk/jvmti/RawMonitorEnter/rawmonenter003
  nsk/jvmti/RawMonitorExit/rawmonexit003
  nsk/jvmti/RawMonitorNotify/rawmnntfy003
  nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall003
  nsk/jvmti/RawMonitorWait/rawmnwait003

The jvmti RawMonitor magic check expect the RawMonitor pointer passed to
the jvmti function from the agent code to be aligned.
This causes VM to crash with SIGBUS.

The following C-program demonstrates the alignement problem in jvmti:
% cat sigbus.c
int main() {
  int   magic = (int)(('T' << 24) | ('I' << 16) | ('R' << 8) | 'M');
  char arr[]  = "a";
  char str[]  = "invalid raw monitor is very bad";
  int  *ptr   = (int*) str;
  if (ptr[0] != magic) {
     return 0;
  }
  return 99;
}

% cc -xarch=v9 sigbus.c
% a.out
Bus Error


This is the nightly failures analysis:

---------------------------------------------------------------------------
I think you are right.
Most likely a C string can be not aligned to the 32-bit word boundary.
Theb the is_valid() code is going to crash at the comparison instruction:
   _magic == JVMTI_RM_MAGIC

class JvmtiRawMonitor : public ObjectMonitor  {
private:
  int           _magic;
  char *        _name;
  // JVMTI_RM_MAGIC is set in contructor and unset in destructor.
  enum { JVMTI_RM_MAGIC = (int)(('T' << 24) | ('I' << 16) | ('R' << 8) | 'M') };

public:
  ...
  bool        is_valid()   { return _magic == JVMTI_RM_MAGIC;  }
};

If the above is true then it is a bug in the is_valid() code
where bytes can be compared instead of int's.
I'm puzzled why we never saw this problem before.

Sure, you can take this item if you want.  :) 

Thanks,
Serguei

Daniel D. Daugherty wrote:

> I suspect memory alignment is the key. A char array doesn't have
> alignment restrictions. Depending on where the char array aligns
> I suspect we'll get SIGBUS.
>
> I suspect if the test is whacked to cycle through the first 8
> bytes in a loop, then it will always blow up at some point, i.e.,
>
>    &bad_bug[0] .. &bad_bug[7]
>
> Evil, but interesting...
> Dan
---------------------------------------------------------------------------

First, all 5 tests got SIGBUS when they pass bad monitor pointers like this:
  static char bad_buf[] = "this is a bad raw monitor";
  static jrawMonitorID bad_monitor = (jrawMonitorID)bad_buf;

and expecting to get the JVMTI_ERROR_INVALID_MONITOR error code
from the RawMonitor* functions:
    err = (*jvmti)->RawMonitorEnter(jvmti, bad_monitor);
    if (err != JVMTI_ERROR_INVALID_MONITOR) {
        printf("Error expected: JVMTI_ERROR_INVALID_MONITOR,\n");
        printf("\tactual: %s (%d)\n", TranslateError(err), err);
        result = FAILED;
    }

hs_err logs show that SIGBUS really happen in the up-level jvmti jvmtiEnter.cpp
functions which should catch the condition "!rmonitor->is_valid()":

jvmti_RawMonitorEnter(jvmtiEnv* env,
            jrawMonitorID monitor) {
  ...

    JvmtiRawMonitor *rmonitor = (JvmtiRawMonitor *)monitor;
  if (rmonitor == NULL) {
      return JVMTI_ERROR_INVALID_MONITOR;
  }
  if (!rmonitor->is_valid()) {
      return JVMTI_ERROR_INVALID_MONITOR;
  }

The test never failed before, but only on 2007.06.02
and on several 64-bit plaforms at once:

nsk/jvmti/RawMonitorExit/rawmonexit003    Servicability New Solaris-AMD64    2007-06-02
nsk/jvmti/RawMonitorExit/rawmonexit003    Servicability New 64BITWIN-AMD64   2007-06-02
nsk/jvmti/RawMonitorExit/rawmonexit003    Servicability New Solaris-SparcV9  2007-06-02

Thanks,
Serguei


Daniel D. Daugherty wrote:

> Greetings,
>
> This nightly was a %$#@ train wreck. It took 3+ hours to analyze this
> mess. There are couple of possible real issues, but most of this is
> just infrastructure noise.
>
> New:

...

>     Serguei, please see the RawMonitor failures on 2007.06.02. This
>         nightly was a train wreck so these failures may not be real.
>         I didn't find anything obvious, but...

> New nsk.jvmti failures (from 2007.06.02)
> *   nsk/jvmti/RawMonitorEnter/rawmonenter003
> *   nsk/jvmti/RawMonitorExit/rawmonexit003
> *   nsk/jvmti/RawMonitorNotify/rawmnntfy003
> *   nsk/jvmti/RawMonitorNotifyAll/rawmnntfyall003
> *   nsk/jvmti/RawMonitorWait/rawmnwait003
>         These tests failed due to SIGBUS on Solaris SPARC-64 Server VM
>         machine nyny). Other tests passed before, after and interleaved
>         with these failing tests. I didn't find anything suspicious in
>         /var/adm/messages during the time the tests were run.
>
>         Note: the subsuite page identifies the config as Solaris SPARC
>         Server VM, but the hs_err_pid file correctly shows the config
>         as Solaris SPARC-64 Server VM.
>
...
> URL: http://gtee.sfbay/gtee/results/MUSTANG/NIGHTLY/VM-MAIN/2007-06-02/Serv_Baseline/
> VM Build: 20070531193122.dcubed.service_hs_b14_merge.2 (same VM as previous run) 
-----------------------------------------------------------------------------------

This is one of the hs_err logs below:

ss45998@nyny hs_err --jvm=/home/ss45998/libjvm.so hs_err_pid28405.log | c++filt
;; Using jvm: /home/ss45998/libjvm.so
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff7bdb802c, pid=28405, tid=4
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20070531193122.dcubed.service_hs_b14_merge.2-fastdebug compiled mode solaris-sparc)
# Problematic frame:
# V  [libjvm.so+0x9b802c]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x000000010013ec00):  JavaThread "main" [_thread_in_native, id=4, stack(0xffffffff7a202000,0xffffffff7a301c50)]

siginfo:si_signo=SIGBUS: si_errno=0, si_code=1 (BUS_ADRALN), si_addr=0xffffffff79d15dcd;; 

Registers:
 O0=0x0000000000000001 O1=0xffffffff7b8a1720 O2=0x0000000000000001 O3=0x0000000000000000
 O4=0x0000000000000000 O5=0xffffffff7b8a1588 O6=0xffffffff7a300691 O7=0xffffffff7bdb8008
 G1=0x007ff0000042efad G2=0x007fffffffbd180e G3=0x00000ffffffff7a3 G4=0x00000000000acb28
 G5=0x00000000000ac800 G6=0x0000000000000000 G7=0xffffffff7a301c50 Y=0x0000000000000000
 PC=0xffffffff7bdb802c nPC=0xffffffff7bdb803c


Top of Stack: (sp=0xffffffff7a300e90)
0xffffffff7a300e90:   ffffffff7d474e20 ffffffff7d41eb31
0xffffffff7a300ea0:   0000000000075e51 0000000000075c00
0xffffffff7a300eb0:   000000010013ec00 ffffffff7a301c50
0xffffffff7a300ec0:   0000000000000d68 ffffffff7d455808
0xffffffff7a300ed0:   000000010011a3e8 ffffffff79d15d25
0xffffffff7a300ee0:   0000000000000064 00000000000001ad
0xffffffff7a300ef0:   ffffffff7d474e20 ffffffff7d3a8ce0
0xffffffff7a300f00:   ffffffff7a300741 ffffffff79c0d480
0xffffffff7a300f10:   0000000000000000 000000010013ec00
0xffffffff7a300f20:   000000010013ec00 0000000000000001
0xffffffff7a300f30:   0000000000000000 0000000010000000
0xffffffff7a300f40:   0000000000000000 0000000000000004
0xffffffff7a300f50:   ffffffff7d41f220 0000000000000003
0xffffffff7a300f60:   0000000000000000 ffffffff7a301450
0xffffffff7a300f70:   000000010013f918 0000000000000000
0xffffffff7a300f80:   000000010011a3f0 ffffffff79d15d18 

Instructions: (pc=0xffffffff7bdb802c)
0xffffffff7bdb801c:   b0 10 20 73 81 c7 e0 08 81 e8 20 00 2a c6 40 05
0xffffffff7bdb802c:   e2 06 60 a8 b0 10 20 32 81 c7 e0 08 81 e8 20 00 
;; Using jvm: /home/ss45998/libjvm.so
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff7bdb802c, pid=28405, tid=4
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20070531193122.dcubed.service_hs_b14_merge.2-fastdebug compiled mode solaris-sparc)
# Problematic frame:
# V  [libjvm.so+0x9b802c]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x000000010013ec00):  JavaThread "main" [_thread_in_native, id=4, stack(0xffffffff7a202000,0xffffffff7a301c50)]

siginfo:si_signo=SIGBUS: si_errno=0, si_code=1 (BUS_ADRALN), si_addr=0xffffffff79d15dcd;; 

Registers:
 O0=0x0000000000000001 O1=0xffffffff7b8a1720 O2=0x0000000000000001 O3=0x0000000000000000
 O4=0x0000000000000000 O5=0xffffffff7b8a1588 O6=0xffffffff7a300691 O7=0xffffffff7bdb8008
 G1=0x007ff0000042efad G2=0x007fffffffbd180e G3=0x00000ffffffff7a3 G4=0x00000000000acb28
 G5=0x00000000000ac800 G6=0x0000000000000000 G7=0xffffffff7a301c50 Y=0x0000000000000000
 PC=0xffffffff7bdb802c nPC=0xffffffff7bdb803c


Top of Stack: (sp=0xffffffff7a300e90)
0xffffffff7a300e90:   ffffffff7d474e20 ffffffff7d41eb31
0xffffffff7a300ea0:   0000000000075e51 0000000000075c00
0xffffffff7a300eb0:   000000010013ec00 ffffffff7a301c50
0xffffffff7a300ec0:   0000000000000d68 ffffffff7d455808
0xffffffff7a300ed0:   000000010011a3e8 ffffffff79d15d25
0xffffffff7a300ee0:   0000000000000064 00000000000001ad
0xffffffff7a300ef0:   ffffffff7d474e20 ffffffff7d3a8ce0
0xffffffff7a300f00:   ffffffff7a300741 ffffffff79c0d480
0xffffffff7a300f10:   0000000000000000 000000010013ec00
0xffffffff7a300f20:   000000010013ec00 0000000000000001
0xffffffff7a300f30:   0000000000000000 0000000010000000
0xffffffff7a300f40:   0000000000000000 0000000000000004
0xffffffff7a300f50:   ffffffff7d41f220 0000000000000003
0xffffffff7a300f60:   0000000000000000 ffffffff7a301450
0xffffffff7a300f70:   000000010013f918 0000000000000000
0xffffffff7a300f80:   000000010011a3f0 ffffffff79d15d18 

Instructions: (pc=0xffffffff7bdb802c)
0xffffffff7bdb801c:   b0 10 20 73 81 c7 e0 08 81 e8 20 00 2a c6 40 05
0xffffffff7bdb802c:   e2 06 60 a8 b0 10 20 32 81 c7 e0 08 81 e8 20 00 
;; 
Stack: [0xffffffff7a202000,0xffffffff7a301c50],  sp=0xffffffff7a300e90,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9b802c];;  jvmti_RawMonitorWait+0x144
C  [librawmnwait003.so+0xd488];;  Inject+0x1e0
J  nsk.jvmti.RawMonitorWait.rawmnwait003.check()I
J  nsk.jvmti.RawMonitorWait.rawmnwait003.run([Ljava/lang/String;Ljava/io/PrintStream;)I
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)
V  [libjvm.so+0x6fef58];;  void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*)+0x9a8
V  [libjvm.so+0x6fe55c];;  void JavaCalls::call(JavaValue*,methodHandle,JavaCallArguments*,Thread*)+0x74
V  [libjvm.so+0x749604];;  void jni_invoke_static(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*)+0xa94
V  [libjvm.so+0x7a2d64];;  jni_CallStaticVoidMethod+0xaa4
C  [java+0x3ed0];;  JavaMain+0x1928

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  nsk.jvmti.RawMonitorWait.rawmnwait003.check()I
J  nsk.jvmti.RawMonitorWait.rawmnwait003.run([Ljava/lang/String;Ljava/io/PrintStream;)I
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x0000000100271000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=11, stack(0xffffffff6a602000,0xffffffff6a701c50)]
  0x000000010026dc00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=10, stack(0xffffffff6a802000,0xffffffff6a901c50)]
  0x000000010026b400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=9, stack(0xffffffff6aa02000,0xffffffff6ab01c50)]
  0x0000000100269800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=8, stack(0xffffffff6ac02000,0xffffffff6ad01c50)]
  0x0000000100243800 JavaThread "Finalizer" daemon [_thread_blocked, id=7, stack(0xffffffff6ae02000,0xffffffff6af01c50)]
  0x000000010023c800 JavaThread "Reference Handler" daemon [_thread_blocked, id=6, stack(0xffffffff6b002000,0xffffffff6b101c50)]
=>0x000000010013ec00 JavaThread "main" [_thread_in_native, id=4, stack(0xffffffff7a202000,0xffffffff7a301c50)]

Other Threads:
  0x0000000100235800 VMThread [stack: 0xffffffff6b202000,0xffffffff6b301c50] [id=5]
  0x0000000100284000 WatcherThread [stack: 0xffffffff6a402000,0xffffffff6a501c50] [id=12]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

...

                                    

Comments
EVALUATION

The problem is clear from the description.
                                     
2007-06-08
SUGGESTED FIX

This is the email discussion below suggesting the fix for this bug.

---------------------------------------------------------------
Right.
It is better to check the alignment and then compare integers.
Checking other places where pointers can be passed from agents
to jvmti must be a part of the bug fix.

Thanks,
Serguei

Swamy V wrote:

> In this case it is easy to check the magic by bytes and
> if by coincidence, few bytes of badly aligned memory
> matches the magic then it will crash at some other
> location. So it is also better to add memory alignment
> check in the code and before checking magic.
> 
> And also there may be other cases we may see this type
> of problem in jvmti.  It is better to check the possibility
> of tools sending badly aligned memory. It is hard to
> protect vm crash from bad jvmti agents.
> 
> -Swamy
---------------------------------------------------------------
                                     
2007-06-08
SUGGESTED FIX

See attached 6567360-webrev-cr0.tgz for the proposed fix.
                                     
2009-02-23
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2f716c0acb64
                                     
2009-03-03



Hardware and Software, Engineered to Work Together