RFR(S): 7145419 com/sun/jdi/JdbMethodExitTest.sh fails when a background thread is generating events.

[Daniel D. Daugherty]

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.auno at 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