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
>
