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: http://cr.openjdk.java.net/~sla/7145419/webrev.01/
test/com/sun/jdi/JdbMethodExitTest.sh
No comments.
test/com/sun/jdi/ShellScaffold.sh
line 1048: echo "apa $res"
Debug output?
Thumbs up.
Dan
Thanks,
/Staffan
On 31 okt 2013, at 13:39, Daniel D. Daugherty <daniel.daughe...@oracle.com>
wrote:
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 uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
VM Started: Set deferred breakpoint Hello.main
Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0
3 System.out.println("Hello World!");
main[1] threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)0x141 Reference Handler cond.
waiting
(java.lang.ref.Finalizer$FinalizerThread)0x140 Finalizer cond. waiting
(java.lang.Thread)0x13f Signal Dispatcher running
Group main:
(java.lang.Thread)0x1 main running (at breakpoint)
(java.lang.Thread)0x260 Thread-1 running
main[1]
but is definitely more work.
Dan
On 10/30/13 8:53 AM, Staffan Larsen wrote:
I think the number in the prompt is the current frame number:
main[1] where
[1] JdbMethodExitTest.bkpt (JdbMethodExitTest.java:84)
[2] JdbMethodExitTest.main (JdbMethodExitTest.java:118)
main[1] up
main[2] where
[2] JdbMethodExitTest.main (JdbMethodExitTest.java:118)
On 30 okt 2013, at 13:26, Staffan Larsen <staffan.lar...@oracle.com> wrote:
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 Started: Set deferred breakpoint JdbMethodExitTest.bkpt()
Breakpoint hit: "thread=main", JdbMethodExitTest.bkpt(), line=84 bci=0
84 int i = 0; //@1 breakpoint
main[1] threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)0x17c Reference Handler cond.
waiting
(java.lang.ref.Finalizer$FinalizerThread)0x17b Finalizer cond.
waiting
(java.lang.Thread)0x17a Signal Dispatcher running
Group main:
(java.lang.Thread)0x1 main running (at
breakpoint)
main[1] thread 0x17a
Signal Dispatcher[1]
If the thread number was part of the prompt, I would have expected that last line to say
"Signal Dispatcher[17a]".
/Staffan
On 30 okt 2013, at 13:10, Daniel D. Daugherty <daniel.daughe...@oracle.com>
wrote:
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
VM Started: Set deferred breakpoint Hello.main
Breakpoint hit: "thread=main", Hello.main(), line=3 bci=0
3 System.out.println("Hello World!");
main[1]
where you feed these cmds to jdb:
stop in Hello.main
run
and your script checks for
Breakpoint hit: "thread=main"
and then pulls the number out of the prompt that follows:
main[1]
Dan
On 10/30/13 7:10 AM, Staffan Larsen wrote:
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 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 extra "cont" were needed.
webrev: http://cr.openjdk.java.net/~sla/7145419/webrev.00/
Would it be possible to set a breakpoint in main (or some other known location)
to determine the thread id (as we do in some of the JDI tests) to make sure we
have the right one before continuing with the rest of the test?
Mikael
