I’m still not happy with this fix since I think the extra output stream synchronization logic is not needed - the debuggee should be suspended at all the interesting points. The fix I proposed is cleaner and (as far as I can tell) also fixes the problem. The only thing is that I can’t quite explain what goes wrong without the fix… I’d really like to understand that. I’ll try to dig deeper and see if I can understand exactly what happens.
/Staffan On 12 feb 2014, at 18:04, shanliang <shanliang.ji...@oracle.com> wrote: > Staffan Larsen wrote: >> >> I think what you need to do is wait for the VMStartEvent before you add >> requests to the VM. Note this paragraph from the VirtualMachine doc: >> >> Note that a target VM launched by a launching connector is not >> guaranteed to be stable until after the VMStartEvent has been >> received. >> > I may miss something here, I believe VMStartEvent must be the first event, > when the test got ClassPrepareEvent, it must already received VMStartEvent. >> >> I think adding code that looks something like this will make the test stable: >> >> VirtualMachine vm = launchTarget(CLASS_NAME); >> EventQueue eventQueue = vm.eventQueue(); >> >> boolean started = false; >> while(!started) { >> EventSet eventSet = eventQueue.remove(); >> for (Event event : eventSet) { >> if (event instanceof VMStartEvent) { >> started = true; >> } >> if (event instanceof VMDeathEvent >> || event instanceof VMDisconnectEvent) { >> throw new Error("VM died before it started...:"+event); >> } >> } >> } >> >> System.out.println("Vm launched"); >> > The code you proposed could improve the test, it made sure that > TestPostFieldModification was started, but I am afraid that it did not > address the issue causing the failure, the issue I believe was that > TestPostFieldModification exited before or during FieldMonitor called > addFieldWatch(), that was why addFieldWatch() received > VMDisconnectedException. When the test was treating ClassPrepareEvent, even > if VMDeathEvent or VMDisconnectEvent arrived, it must be still waiting in the > eventQueue because it arrived after ClassPrepareEvent. > > My fix was to not allow TestPostFieldModification to exit before > addFieldWatch() was done. >> >> >> There is also no reason to call addFieldWatch() before the ClassPrepareEvent >> has been received. The call to vm..classesByName() will just return an empty >> list anyway. >> > I do not know why the test called addFieldWatch before ClassPrepareEvent had > been received, but yes the returned list was empty, so agree to remove it. >> While you are in there you can also remove the unused StringBuffer near the >> top of main(). >> > Yes it was already removed in version 01 > > Here is the new webrev: > http://cr.openjdk.java.net/~sjiang/JDK-8007710/02/ > > Thanks, > Shanliang >> >> Thanks, >> /Staffan >> >> On 11 feb 2014, at 18:30, shanliang <shanliang.ji...@oracle.com> wrote: >> >> >>> Here is the new fix in which FieldMonitor will write to >>> TestPostFieldModification, to inform the latter to quit, as suggested bu >>> Jaroslav >>> http://cr.openjdk.java.net/~sjiang/JDK-8007710/01/ >>> >>> Thanks, >>> Shanliang >>> >>> shanliang wrote: >>> >>>> shanliang wrote: >>>> >>>>> Jaroslav Bachorik wrote: >>>>> >>>>>> On 11.2.2014 16:31, shanliang wrote: >>>>>> >>>>>>> Staffan Larsen wrote: >>>>>>> >>>>>>>> Hi Shanliang, >>>>>>>> >>>>>>>> I can’t quite see how the test can fail in this way. When the >>>>>>>> ClassPrepareEvent happens, the debuggee will be suspended. So when >>>>>>>> addFieldWatch() is called, the debuggee should not have moved. >>>>>>>> >>>>>>> I am not expert of jdi so I may miss something here. I checked the >>>>>>> failure trace and saw the report exception happen when FieldMonitor >>>>>>> received ClassPrepareEvent and was doing addFieldWatch. FieldMonitor did >>>>>>> call "vm.resume()" before treating events. >>>>>>> >>>>>> AFAICS, calling vm.resume() results in an almost immediate debuggee >>>>>> death. The gc() invoking thread "d" is flagged as a deamon and as such >>>>>> doesn't prevent the process from exiting. The other thread is not a >>>>>> daemon but will finish in only few cycles. >>>>>> >>>>> I looked at the class com.sun.jdi.VirtualMachine, here is the Javadoc of >>>>> the method "resume": >>>>> /** >>>>> * Continues the execution of the application running in this >>>>> * virtual machine. All threads are resumed as documented in >>>>> * {@link ThreadReference#resume}. >>>>> * >>>>> * @throws VMCannotBeModifiedException if the VirtualMachine is >>>>> read-only - see {@link VirtualMachine#canBeModified()}. >>>>> * >>>>> * @see #suspend >>>>> */ >>>>> void resume(); >>>>> My understanding is that the debuggee resumes to work after this call, >>>>> instead to die? >>>>> >>>> In fact the problem is here, the vm (TestPostFieldModification) should not >>>> die before FieldMonitor finishes addFieldWatch. >>>> >>>> Shanliang >>>> >>>>>>> I reproduced the bug by add sleep(1000) after vm.resume() but before >>>>>>> calling eventQueue.remove(); >>>>>>> >>>>>> It looks like some kind of synchronization between the debugger and the >>>>>> debuggee is necessary. But I wonder if you should better use the >>>>>> process.getOuptuptStream() to write and flush a message for the debugee >>>>>> indicating that it can exit. And in the debugee you would just do >>>>>> System.in.read() as the last statement in the main() method. Seems more >>>>>> robust than involving files. >>>>>> >>>>> It could work, but creating a file in the testing directory should have >>>>> no issue, but yes maybe less performance. >>>>> >>>>> Thanks, >>>>> Shanliang >>>>> >>>>>> Cheers, >>>>>> >>>>>> -JB- >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Shanliang >>>>>>> >>>>>>>> One problem I do see with the test is that it does not wait for a >>>>>>>> VMStartEvent before setting up requests. I’m not sure if that could >>>>>>>> cause the failure in the bug report, though. >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 11 feb 2014, at 15:13, shanliang <shanliang.ji...@oracle.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi , >>>>>>>>> >>>>>>>>> The problem could be that FieldMonitor did not have enough time to >>>>>>>>> "addFieldWatch" but the vm to monitor (TestPostFieldModification) was >>>>>>>>> already ended. >>>>>>>>> >>>>>>>>> So we should make sure that TestPostFieldModification exits after >>>>>>>>> FieldMonitor has done necessary. The solution proposed here is that >>>>>>>>> FieldMonitor creates a file after adding field watching, and >>>>>>>>> TestPostFieldModification quits only after finding the file. >>>>>>>>> >>>>>>>>> web: >>>>>>>>> http://icncweb.fr.oracle.com/~shjiang/webrev/8007710/00/ >>>>>>>>> >>>>>>>>> bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8007710 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Shanliang >>>>>>>>> >>>>>>> >> > >