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

[Daniel D. Daugherty]

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.daugherty at 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.larsen at 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.daugherty at 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.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