The testcase is
    nsk/jvmdi/GetFrameLocation/frameloc001

GetFrameLocation returns the location after the monitor enter.
It should return the location _of_ the monitorenter.

See also bug 4527281 for a different bug when this test is run in -Xcomp mode.

This is on solsparc.


Name: ipR10196 Date: 08/26/2003


Similar bug is revealed for the corresponding JVMTI function
GetFrameLocation(). The tests affected are:

  nsk/jvmti/GetFrameLocation/frameloc001

Ivan Popov <###@###.###>

======================================================================

The following is another test and appearance of the same bug described by Jim
which I took from the duplicated bug report for convenience:
   4791832: Wrong location reported for a thread stopped on a contended monitor

-------------------------------------------------------------------
A test for this is in regressionTestsInWaiting/SyncLineNumberTest.sh.

Basically, it uses jdb to stop at a line (eg line 12) that contains
   synchronized(object1) {
where the monitor for object1 is already locked. It then does
a 'next' which causes the thread to wait for the monitor. If the thread is
suspended, we find that its location is now the BCI for line 13. It should
still be the BCI of the monitorenter which will cause the line
number to be reported as 12.

This test passes on IA64.
See also
   4787861 JDI: wrong location of step event after thrown exception
-------------------------------------------------------------------
###@###.### 2005-07-22 01:36:00 GMT