-
Bug
-
Resolution: Won't Fix
-
P4
-
7
-
generic
-
generic
Here is the entry from my "service_hs nightly analysis
2008.01.22 (final)" report:
New nsk.jdb failures (from 2007.03.10)
nsk/jdb/step/step002
This test failed due to "ERROR: CASE #1 FAILED: Wrong location
after step inside current method" on Solaris SPARC Client VM
(machine vm-b1600s-1).
The test is looking for the following:
// case #1 : step inside frame;
reply = jdb.receiveReplyFor(JdbCommand.step);
reply = jdb.receiveReplyFor(JdbCommand.eval + "intVar");
grep = new Paragrep(reply);
if (grep.find("1234") == 0) {
failure("CASE #1 FAILED: Wrong location after step inside current method");
}
From the jdb.session log, an "eval intVar" command was issued,
but there is no output from the command.
This test failed twice previously on machine queequay, but we
invalidated those failures because machine queequay had chronic
disk space shortages which are being tracked by issue #201.
Machine vm-b1600s-1 does not appear to have a disk space issue,
unless the root partition is being used:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s0 8067749 7739733 247339 97% /
/dev/dsk/c0t0d0s7 15746834 15633 15573733 1% /export/home
I checked /var/adm/messages.0 and found no out of disk space
messages. I did find NFS4 error message, but those were many
hours before and a couple of hours after this test ran.
Update: Nightly results from 2007.03.10, 2007.07.09 or
2007.10.02 are no longer available and nightly search did
not find any recent valid failures. Due to a lack of
information, I will delete this entry in the next report.
Last failure on 2007.10.02 with Solaris SPARC-64 Server VM.
Previous failure on 2007.07.09 with Solaris SPARC Server VM.
Here is an entry from my nightly analysis report:
New nsk.jdb failures (from 2008.02.05)
* nsk/jdb/step/step002
This test failed due to "ERROR: CASE #1 FAILED: Wrong location
after step inside current method" on Solaris SPARC Server VM
(machine kiang). I used to have an entry for this test that was
removed during the cleanup phase in the "service_hs nightly
analysis 2008.01.22 (final)" report.
2008.01.22 (final)" report:
New nsk.jdb failures (from 2007.03.10)
nsk/jdb/step/step002
This test failed due to "ERROR: CASE #1 FAILED: Wrong location
after step inside current method" on Solaris SPARC Client VM
(machine vm-b1600s-1).
The test is looking for the following:
// case #1 : step inside frame;
reply = jdb.receiveReplyFor(JdbCommand.step);
reply = jdb.receiveReplyFor(JdbCommand.eval + "intVar");
grep = new Paragrep(reply);
if (grep.find("1234") == 0) {
failure("CASE #1 FAILED: Wrong location after step inside current method");
}
From the jdb.session log, an "eval intVar" command was issued,
but there is no output from the command.
This test failed twice previously on machine queequay, but we
invalidated those failures because machine queequay had chronic
disk space shortages which are being tracked by issue #201.
Machine vm-b1600s-1 does not appear to have a disk space issue,
unless the root partition is being used:
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s0 8067749 7739733 247339 97% /
/dev/dsk/c0t0d0s7 15746834 15633 15573733 1% /export/home
I checked /var/adm/messages.0 and found no out of disk space
messages. I did find NFS4 error message, but those were many
hours before and a couple of hours after this test ran.
Update: Nightly results from 2007.03.10, 2007.07.09 or
2007.10.02 are no longer available and nightly search did
not find any recent valid failures. Due to a lack of
information, I will delete this entry in the next report.
Last failure on 2007.10.02 with Solaris SPARC-64 Server VM.
Previous failure on 2007.07.09 with Solaris SPARC Server VM.
Here is an entry from my nightly analysis report:
New nsk.jdb failures (from 2008.02.05)
* nsk/jdb/step/step002
This test failed due to "ERROR: CASE #1 FAILED: Wrong location
after step inside current method" on Solaris SPARC Server VM
(machine kiang). I used to have an entry for this test that was
removed during the cleanup phase in the "service_hs nightly
analysis 2008.01.22 (final)" report.