| 1c40fe5dbb39eaa6eed3fde3f06effe3517b32d0 |
02-Oct-2014 |
Sebastien Hertz <shertz@google.com> |
Fix OwnedMonitorsStackDepthInfo JDWP tests
Ensure we signal the debuggee to continue at the end of the test. It
should prevent the test from failing because the debuggee remains
blocked while we wait for it to finish.
We set the continue message in the 'finalSyncMessage' field. When the
test ends, it will automatically send the message in this field to
the debuggee.
Bug: 17751850
Change-Id: I3be530230c4ad1b768be18b2136f5580a0af4a6d
wnedMonitorsStackDepthInfoTest.java
|
| 90ce606678947d1dcc22272ecde9ff3f90975caa |
26-Feb-2013 |
Elliott Hughes <enh@google.com> |
Fix OwnedMonitorsStackDepthInfoTest.
We were still relying too much on implementation details, in particular
"where does the test thread actually get suspended?" --- it turned out
that we were usually running fast enough to suspend at the receive, but
sometimes we could suspend at the preceding send.
Also improve the test code so that we check multiple stack frames in
the test code, both with and without held monitors, and from synchronized
methods as well as from synchronized blocks.
Change-Id: Ibda449d097d99b15121076b7cad75383b76ed35d
wnedMonitorsStackDepthInfoDebuggee.java
wnedMonitorsStackDepthInfoTest.java
|
| 84c4b3562698286333166774e54c4c3250e91132 |
16-Jan-2013 |
Elliott Hughes <enh@google.com> |
Fix a typo in OwnedMonitorsStackDepthInfoTest.
Change-Id: Ib95f22dafe162f1d0d67a1a7a66882e3acd9a89a
wnedMonitorsStackDepthInfoTest.java
|
| a1cf4b5cdac1f82af6661cd01fc0f92c6459d99f |
12-Jan-2013 |
Elliott Hughes <enh@google.com> |
ThreadReference.OwnedMonitorsStackDepthInfo is now implemented.
Note that the test was hard-coding stack depths that depend on the
library implementation. Since the stack frames in question are the
outermost two (with all the library frames after them), I've made
the smallest change of asking for the total number of stack frames
and then asserting that we're dealing with the outermost two.
Getting the actual stack frames and checking the actual methods
would be a lot hairier, and not obviously valuable (since we already
test those JDWP requests elsewhere).
Change-Id: Ie56bc862639338d6ae02bc1c08fad3b1e7ed4ef1
wnedMonitorsStackDepthInfoTest.java
|
| 5d36ea7c6bdfa6fbcd1ccd53465fe41d7225273b |
29-Jun-2012 |
Elliott Hughes <enh@google.com> |
Bring the JDWP test timeout down to 10s.
This lets us run the suite in 6 minutes, even with failures (all our current
failures manifest as timeouts, caused by not getting method-entry events from
code compiled without -g).
Change-Id: If8a80b84b47596ed2c3b43637997b781f3f2195e
tatus002Debuggee.java
tatus003Debuggee.java
tatus004Debuggee.java
tatus005Debuggee.java
|
| 5f0a23683aa603d8c50b6dd071a565821b76067b |
10-Dec-2011 |
Elliott Hughes <enh@google.com> |
Add harmony's jdwp tests.
Change-Id: I1c0e70cd9e07244fe422a4f77f3727b55ec28402
urrentContendedMonitorDebuggee.java
urrentContendedMonitorTest.java
orceEarlyReturn002Test.java
orceEarlyReturn003Test.java
orceEarlyReturn004Test.java
orceEarlyReturn005Test.java
orceEarlyReturn006Test.java
orceEarlyReturnDebuggee.java
orceEarlyReturnTest.java
rameCountTest.java
ramesDebuggee.java
ramesTest.java
nterruptDebuggee.java
nterruptTest.java
ameTest.java
wnedMonitorsDebuggee.java
wnedMonitorsStackDepthInfoDebuggee.java
wnedMonitorsStackDepthInfoTest.java
wnedMonitorsTest.java
esumeDebuggee.java
esumeTest.java
tatus002Debuggee.java
tatus002Test.java
tatus003Debuggee.java
tatus003Test.java
tatus004Debuggee.java
tatus004Test.java
tatus005Debuggee.java
tatus005Test.java
tatus006Debuggee.java
tatus006Test.java
tatusDebuggee.java
tatusTest.java
topDebuggee.java
topTest.java
uspendCountDebuggee.java
uspendCountTest.java
uspendDebuggee.java
uspendTest.java
hreadGroup002Debuggee.java
hreadGroup002Test.java
hreadGroupDebuggee.java
hreadGroupTest.java
|