Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

[Chris Plummer]

Hi Gary, Unfortunately GetStackTrace() returns the top frame as the first frame in the array. Thus if the thread is not suspended and later you call GetFrameLocation() for some depth, there's no way to make sure the frame at that depth is the same frame at that depth in the array returned by GetStackTrace() unless you first suspend the frame before calling GetFrameLocation(). You would also need to call GetFrameCount() while suspended, compare that with the number of frames returned by GetStackTrace(), and make any needed depth adjustments. But since I think the intent is to not suspend the thread here, it probably does not make sense to do that, and instead accept that there might be some errors as you have done. One improvement I would like to see for your fix is to only ignore JVMTI_ERROR_NO_MORE_FRAMES rather than ignore all failures when suspended == NSK_TRUE. Also, I don't think you want the suspended check here:  348         /* check if expected method frame found */  349         if ((suspended == NSK_TRUE) && (found <= 0)) { The check for finding the method is:  341             if (frameStack[j].method == threadsDesc[i].method) { Since frameStack[] is returned by GetStackTrace(), it is not impacted when not suspended, and the expected method should always be in frameStack[] somewhere. The issue is only with using GetFrameLocation() to correlate what is in the result of GetStackTrace(). thanks, Chris On 12/13/18 5:25 AM, Gary Adams wrote: While testing I ran into another of the related failures that were associated with the original bug. The following fake exception stacktrace is for failure analysis. nsk.share.Fake_Exception_for_RULE_Creation: (sp02t003.cpp:313) jvmti->GetFrameLocation(threadsDesc[i].thread, j, &qMethod, &qLocation) at nsk_lvcomplain(nsk_tools.cpp:172) # ERROR: sp02t003.cpp, 313: jvmti->GetFrameLocation(threadsDesc[i].thread, j, &qMethod, &qLocation) # jvmti error: code=31, name=JVMTI_ERROR_NO_MORE_FRAMES - sp02t003.cpp, 310: 3 frame: method: 0x7f225042b2d8, location: 16 # ERROR: sp02t003.cpp, 313: jvmti->GetFrameLocation(threadsDesc[i].thread, j, &qMethod, &qLocation) # jvmti error: code=31, name=JVMTI_ERROR_NO_MORE_FRAMES # ERROR: sp02t003.cpp, 350: No expected method frame for not suspended thread #4 (threadRunningInterrupted) In this particular failure, the GetFrameLocation call failed, because the frame was no longer accessible. If the threads are not suspended, the GetFrameLocation may fail, or if it passes, the qMethod and qLocation could belong to another frame. I've updated the webrev to allow the call to GetFrameLocation, but to only report an error if the threads are suspended. Similarly, the checks to compare qMethod and qLocation will be skipped, if the threads are not suspended. And the final comparison that the method was found will only be an error if the threads are suspended.   Webrev: http://cr.openjdk.java.net/~gadams/8051349/webrev.01/ On 12/12/18, 11:54 AM, Gary Adams wrote: After some testing with nsk verbose messages enabled, it is clear that this test is failing in checkThreads when the location did not match between the call to GetStackTrace and GetFrameLocation. For the tests that are run when the threads have not been suspended, there is no guarantee the locations will match.   Issue: https://bugs.openjdk.java.net/browse/JDK-8051349   Webrev: http://cr.openjdk.java.net/~gadams/8051349/webrev.00/