Here is new version that lets the program print the thread id which the test
will pick up and use:
webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.01/
Thanks,
/Staffan
On 31 okt 2013, at 13:39, Daniel D. Daugherty daniel.daughe...@oracle.com
wrote:
I stand corrected. Only the thread
On 1 nov 2013, at 13:44, Daniel D. Daugherty daniel.daughe...@oracle.com
wrote:
On 11/1/13 6:31 AM, Staffan Larsen wrote:
Here is new version that lets the program print the thread id
Hey, that's cheating! :-)
which the test will pick up and use:
webrev:
I stand corrected. Only the thread name is in the prompt.
I think I've been away from 'jdb' too long...
Filtering the output of this might help:
$ jdb Hello
Initializing jdb ...
stop in Hello.main
Deferring breakpoint Hello.main.
It will be set after the class is loaded.
run
run Hello
Set
On 2013-10-29 15:41, Staffan Larsen wrote:
This test fails if there are background threads that run while the
test is running. I've modified the test to use the trace commands
in jdb with the extra thread parameter. I have assumed that the main
thread has thread id 1. trace with thread id
I tried, that, but couldn't find what the jdb command for getting the current
thread is. Anyone?
/Staffan
On 30 okt 2013, at 11:17, Mikael Auno mikael.a...@oracle.com wrote:
On 2013-10-29 15:41, Staffan Larsen wrote:
This test fails if there are background threads that run while the
test is
The current thread number is part of the jdb prompt.
So something like this:
$ jdb Hello
Initializing jdb ...
stop in Hello.main
Deferring breakpoint Hello.main.
It will be set after the class is loaded.
run
run Hello
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
But that does not seem to work correctly:
Initializing jdb ...
stop in JdbMethodExitTest.bkpt()
Deferring breakpoint JdbMethodExitTest.bkpt().
It will be set after the class is loaded.
run
run JdbMethodExitTest
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM
This test fails if there are background threads that run while the test is
running. I've modified the test to use the trace commands in jdb with the
extra thread parameter. I have assumed that the main thread has thread id 1.
trace with thread id behaves a little bit different so a couple of
Looks good, if we can assume main thread has id = 1 (main thread must
use first j.l.Thread object that is created)
/Erik
Staffan Larsen skrev 2013-10-29 15:41:
This test fails if there are background threads that run while the test is running. I've modified the test to
use the trace
