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: 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? Oops. I'll remove that before pushing. Thanks, /Staffan > > 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 >
