United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6993078 JSR 292 too many pushes: Lesp points into register window
JDK-6993078 : JSR 292 too many pushes: Lesp points into register window

Details
Type:
Bug
Submit Date:
2010-10-19
Status:
Closed
Updated Date:
2012-02-01
Project Name:
JDK
Resolved Date:
2011-05-10
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs20,hs21
Fixed Versions:
hs21 (b11)

Related Reports
Backport:
Duplicate:
Duplicate:
Relates:

Sub Tasks

Description
After the fix for 6990192 running loopsAndThreads with a debug build on SPARC results in:

$ gamma -XX:+ShowMessageBoxOnError -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -cp classes:. Test
VM option '+ShowMessageBoxOnError'
VM option '+UseSerialGC'
VM option '+UnlockExperimentalVMOptions'
VM option '+EnableInvokeDynamic'
EXECUTION STOPPED: too many pushes:  Lesp points into register window

==============================================================================
too many pushes:  Lesp points into register window
------------------------------------------------------------------------------
Execution stopped, print registers?
==============================================================================
n
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/assembler_sparc.cpp:1969
==============================================================================
Unexpected Error
------------------------------------------------------------------------------
Internal Error at assembler_sparc.cpp:1969, pid=8944, tid=66
assert(false) failed: error

Do you want to debug the problem?

To debug, run 'dbx - 8944'; then switch to thread 66
Enter 'yes' to launch dbx automatically (PATH must include dbx)
Otherwise, press RETURN to abort...
==============================================================================


(dbx) where
current thread: t@66
  [1] _waitid(0x0, 0x22f1, 0xfffffffe69cfe440, 0x3, 0x0, 0xffffffff7f736540), at 0xffffffff7cddb230 
  [2] _waitpid(0x22f1, 0xfffffffe69cfe6a8, 0x0, 0xffffffff7e6ba618, 0xffffffff75110a00, 0x0), at 0xffffffff7cd7abfc 
  [3] waitpid(0x22f1, 0xfffffffe69cfe6a8, 0x0, 0x0, 0x0, 0xffffffff7cf482a0), at 0xffffffff7cdc9cec 
=>[4] os::fork_and_exec(cmd = 0xffffffff7f206798 "dbx - 8944"), line 5978 in "os_solaris.cpp"
  [5] VMError::show_message_box(this = 0xfffffffe69cfea70, buf = 0xffffffff7f206798 "dbx - 8944", buflen = 2000), line 53 in "vmError_solaris.cpp"
  [6] VMError::report_and_die(this = 0xfffffffe69cfea70), line 725 in "vmError.cpp"
  [7] report_vm_error(file = 0xffffffff7ea21b86 "/home/ct232829/hotspot-comp/6990192/src/cpu/sparc/vm/assembler_sparc.cpp", line = 1969, error_msg = 0xffffffff7ea21bcf "assert(false) failed", detail_msg = 0xffffffff7ea21be4 "error"), line 176 in "debug.cpp"
  [8] MacroAssembler::debug(msg = 0xffffffff7ec4f3d0 "too many pushes:  Lesp points into register window", regs = 0xfffffffe69cfed68), line 1969 in "assembler_sparc.cpp"
  [9] 0xffffffff780006fc(0xfffffffe69cfed68, 0xffffffff7ec4f3d0, 0x0, 0xffffffff78032994, 0x1003aef98, 0xffffffff78000520), at 0xffffffff780006fc 
  [10] 0xffffffff7803876c(0x1c8, 0xa0, 0x8, 0xffffffff78033ed4, 0x0, 0xfffffffe69cfe7f1), at 0xffffffff7803876c 
  [11] 0xffffffff78038750(0xfffffffe74cd03c0, 0xb6, 0x0, 0xffffffff7803870c, 0x0, 0xfffffffe69cfe901), at 0xffffffff78038750 
  [12] 0xffffffff780067f0(0xfffffffe74cdc770, 0xffffffff700509f0, 0x0, 0xffffffff780370a0, 0x1, 0xfffffffe69cfea11), at 0xffffffff780067f0 
  [13] 0xffffffff78007900(0xfffffffe74cd00e0, 0x1003ae000, 0x0, 0xffffffff78037e60, 0xfffffffe69cffa29, 0xfffffffe69cfeb01), at 0xffffffff78007900 
  [14] 0xffffffff78000318(0xfffffffe69cff4d8, 0xfffffffe69cffb90, 0xa, 0xffffffff70052810, 0xffffffff78015600, 0xfffffffe69cff9f0), at 0xffffffff78000318 
  [15] JavaCalls::call_helper(result = 0xfffffffe69cffb88, m = 0xfffffffe69cff758, args = 0xfffffffe69cff9d8, __the_thread__ = 0x1003ae000), line 379 in "javaCalls.cpp"
  [16] os::os_exception_wrapper(f = 0xffffffff7e31d600 = &JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*), value = 0xfffffffe69cffb88, method = 0xfffffffe69cff758, args = 0xfffffffe69cff9d8, thread = 0x1003ae000), line 4083 in "os_solaris.cpp"
  [17] JavaCalls::call(result = 0xfffffffe69cffb88, method = CLASS, args = 0xfffffffe69cff9d8, __the_thread__ = 0x1003ae000), line 293 in "javaCalls.cpp"
  [18] JavaCalls::call_virtual(result = 0xfffffffe69cffb88, spec_klass = CLASS, name = CLASS, signature = CLASS, args = 0xfffffffe69cff9d8, __the_thread__ = 0x1003ae000), line 190 in "javaCalls.cpp"
  [19] JavaCalls::call_virtual(result = 0xfffffffe69cffb88, receiver = CLASS, spec_klass = CLASS, name = CLASS, signature = CLASS, __the_thread__ = 0x1003ae000), line 196 in "javaCalls.cpp"
  [20] thread_entry(thread = 0x1003ae000, __the_thread__ = 0x1003ae000), line 2580 in "jvm.cpp"
  [21] JavaThread::thread_main_inner(this = 0x1003ae000), line 1430 in "thread.cpp"
  [22] JavaThread::run(this = 0x1003ae000), line 1414 in "thread.cpp"
  [23] java_start(thread_addr = 0x1003ae000), line 1010 in "os_solaris.cpp"
(dbx) p ps ()

"Executing ps"
 for thread: "Thread-56" prio=3 tid=0x00000001003ae000 nid=0x42 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_Java
Thread: 0x00000001003ae000  [0x42] State: _running _has_called_back 0 _at_poll_safepoint 0
   JavaThread state: _thread_in_Java

(guessing starting frame id=fffffffe69cfe540 based on current fp)
C frame (sp=0xfffffffe69cfe540 unextended sp=0xfffffffe69cfe540, fp=0xfffffffe69cfe5f0, pc=0xffffffff7cdc9cf4)
C frame (sp=0xfffffffe69cfe5f0 unextended sp=0xfffffffe69cfe5f0, fp=0xfffffffe69cfe6f0, pc=0xffffffff7e6ba620)
C frame (sp=0xfffffffe69cfe6f0 unextended sp=0xfffffffe69cfe6f0, fp=0xfffffffe69cfe7e0, pc=0xffffffff7e9682f0)
C frame (sp=0xfffffffe69cfe7e0 unextended sp=0xfffffffe69cfe7e0, fp=0xfffffffe69cfe9b0, pc=0xffffffff7e966a24)
C frame (sp=0xfffffffe69cfe9b0 unextended sp=0xfffffffe69cfe9b0, fp=0xfffffffe69cfeb10, pc=0xffffffff7e0ea3cc)
C frame (sp=0xfffffffe69cfeb10 unextended sp=0xfffffffe69cfeb10, fp=0xfffffffe69cfec00, pc=0xffffffff7dd36b84)
C frame (sp=0xfffffffe69cfec00 unextended sp=0xfffffffe69cfec00, fp=0xfffffffe69cfecb0, pc=0xffffffff78000704)
(~Stub::stop_subroutine)
     BufferBlob (0xffffffff78000110) used for StubRoutines (1)

 1 - frame( sp=0xfffffffe69cfecb0, unextended_sp=0xfffffffe69cfecb0, fp=0xfffffffe69cfeff0, pc=0xffffffff78038774)
Test.target
 2 - frame( sp=0xfffffffe69cfeff0, unextended_sp=0xfffffffe69cfeff0, fp=0xfffffffe69cff0f0, pc=0xffffffff78038758)
Test.runThread(Test.java:73)
 3 - frame( sp=0xfffffffe69cff0f0, unextended_sp=0xfffffffe69cff100, fp=0xfffffffe69cff200, pc=0xffffffff780067f8)
vm.mlvm.share.MultiThreadedTest$1.run(MultiThreadedTest.java:32)
 4 - frame( sp=0xfffffffe69cff200, unextended_sp=0xfffffffe69cff210, fp=0xfffffffe69cff300, pc=0xffffffff78007908)
java.lang.Thread.run(Thread.java:729)
register window backtrace from 0x69cfe540:
[0] sp=0x69cfe540 pc=0x0000000000000000 is pointing to unknown location
[1] sp=0x69cfe5f0 pc=0x000000007e6ba618 is pointing to unknown location
[2] sp=0x69cfe6f0 pc=0x000000007e9682e8 is pointing to unknown location
[3] sp=0x69cfe7e0 pc=0x000000007e966a1c is pointing to unknown location
[4] sp=0x69cfe9b0 pc=0x000000007e0ea3c4 is pointing to unknown location
[5] sp=0x69cfeb10 pc=0x000000007dd36b7c is pointing to unknown location
[6] sp=0x69cfec00 pc=0x00000000780006fc is pointing to unknown location
[7] sp=0x69cfecb0 pc=0x000000007803876c is pointing to unknown location
[8] sp=0x69cfeff0 pc=0x0000000078038750 is pointing to unknown location
[9] sp=0x69cff0f0 pc=0x00000000780067f0 is pointing to unknown location
[10] sp=0x69cff200 pc=0x0000000078007900 is pointing to unknown location
[11] sp=0x69cff300 pc=0x0000000078000318 is pointing to unknown location
[12] sp=0x69cff3c0 pc=0x000000007e31de64 is pointing to unknown location
[13] sp=0x69cff5b0 pc=0x000000007e6b3ca4 is pointing to unknown location
[14] sp=0x69cff690 pc=0x000000007e31d5d8 is pointing to unknown location
[15] sp=0x69cff770 pc=0x000000007e31c578 is pointing to unknown location
[16] sp=0x69cff910 pc=0x000000007e31c68c is pointing to unknown location
[17] sp=0x69cffa90 pc=0x000000007e3eba3c is pointing to unknown location
[18] sp=0x69cffbf0 pc=0x000000007e8cac48 is pointing to unknown location
[19] sp=0x69cffd50 pc=0x000000007e8caac0 is pointing to unknown location
[20] sp=0x69cffe60 pc=0x000000007e6a7dc8 is pointing to unknown location
[21] sp=0x69cfff50 pc=0x000000007cdd6ee0 is pointing to unknown location
[22] sp=0x7ff [bogus sp!]ps() = (void)
(dbx) fr 9
0xffffffff780006fc:     call     debug  ! 0xffffffff7dd36958
(dbx) p findpc($pc)
dbx: warning: unknown language, 'c' assumed
dbx: internal warning: don't know how to convert to integral type from
pointer (null)
 base integer $int

"Executing findpc"
StubRoutines::stop_subroutine [0xffffffff78000520, 0xffffffff78000840[ (800 bytes)
findpc($pc) = (void)
(dbx) up
0xffffffff7803876c:     call     %o5
(dbx) p findpc($pc) 
dbx: internal warning: don't know how to convert to integral type from
pointer (null)
 base integer $int

"Executing findpc"
invokedynamic  186 invokedynamic  [0xffffffff78038580, 0xffffffff780389e0]  1120 bytes
findpc($pc) = (void)
(dbx)

                                    

Comments
EVALUATION

This is actually an interpreter bug as it happens with -Xint.
                                     
2010-12-21
EVALUATION

Can be reproduced with -Xint on 32 and 64-bit SPARC and 64-bit x86, but runs fine on 32-bit x86.
                                     
2010-12-21
EVALUATION

With -Xmixed on 32-bit x86:

Internal Error at sharedRuntime.cpp:2747, pid=29575, tid=14
assert(fr.interpreter_frame_expression_stack_size()==0) failed: only handle empty stacks
                                     
2010-12-21
EVALUATION

Since the invokedynamic syntax is gone and the testcase was rewritten, it's not possible to reproduce this bug anymore.  Maybe it would be possible to produce the same bytecode sequence as the original testcase had with a tool like ASM but for now I'm closing this bug as not reproducible.
                                     
2011-03-23
EVALUATION

I was able to reproduce the bug on vmsqe-t2000b with a recent version of loopsAndThreads:

vmsqe-t2000b:/tmp/twisti$ while true; do ./2011-04-18-083529.ct232829.7018355-fastdebug/bin/java -XX:+CheckUnhandledOops -showversion -XX:+ShowMessageBoxOnError -XX:+UseSerialGC -cp vm7-jsr292-release-2011-04-14.jar vm.mlvm.indy.stress.java.loopsAndThreads.INDIFY_Test -stressIterationsFactor 1000000 -stressThreadsFactor 1000 -stressTime 600; done
VM option '+CheckUnhandledOops'
VM option '+ShowMessageBoxOnError'
VM option '+UseSerialGC'
java version "1.7.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b138)
Java HotSpot(TM) Server VM (build 21.0-b08-internal-201104180835.ct232829.7018355-fastdebug, mixed mode)

Stress time: 600 seconds
Stress iterations factor: 1000000
Stress threads factor: 1000
EXECUTION STOPPED: too many pushes:  Lesp points into register window

==============================================================================
too many pushes:  Lesp points into register window
------------------------------------------------------------------------------
Execution stopped, print registers?
==============================================================================
                                     
2011-04-20
EVALUATION

It also reproduces on dr-good.  The smallest configuration I could find so far which almost always triggers is:

dr-good:/export/twisti$ ./2011-04-18-083529.ct232829.7018355-fastdebug/bin/java -XX:+CheckUnhandledOops -showversion -XX:+ShowMessageBoxOnError -XX:+UseSerialGC -cp vm7-jsr292-release-2011-04-14.jar vm.mlvm.indy.stress.java.loopsAndThreads.INDIFY_Test -stressIterationsFactor 1000 -stressThreadsFactor 10 -stressTime 600
VM option '+CheckUnhandledOops'
VM option '+ShowMessageBoxOnError'
VM option '+UseSerialGC'
java version "1.7.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.7.0-ea-fastdebug-b138)
Java HotSpot(TM) Server VM (build 21.0-b08-internal-201104180835.ct232829.7018355-fastdebug, mixed mode)

Stress time: 600 seconds
Stress iterations factor: 1000
Stress threads factor: 10
EXECUTION STOPPED: too many pushes:  Lesp points into register window

==============================================================================
too many pushes:  Lesp points into register window
------------------------------------------------------------------------------
Execution stopped, print registers?
==============================================================================
                                     
2011-04-20
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/08ccee2c4dbf
                                     
2011-04-21
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/08ccee2c4dbf
                                     
2011-05-05



Hardware and Software, Engineered to Work Together