There is a bug in NotifyFramePop that causes it to miss the FRAME_POP event if the NotifyFramePop is done as the frame is being returned from. It appears that if you call SuspendThread at just the right time during the method return, the thread will be suspended before the frame is popped, but after the check to see if a FRAME_POP event should be generated. When this happens, it also appears that the NotifyFramePop is still put in place, and stays in place after the frame has been popped. It will then trigger a FRAME_POP even the next time the thread returns from that same frame depth, even though it is returning from a totally different method than the one that was current want NotifyFramePop was called.

I’ve written a test that demonstrates this behavior. The main thread of the test (the one that NotifyFramePop is called on) does the following

    for (int i = 0; i < 1000*1000; i++) {
        foo();
        bar();
    }

    private static int fetchInt() {
        return 13;
    }

    private static int foo() {
        return fetchInt();
    }

    private static int bar() {
        return fetchInt();
    }


There is another thread that continually does a NotifyFramePop on the above thread. It calls SuspendThread before the NotifyFramePop and ResumeThread after. It waits for the FRAME_POP event before doing the next NotifyFramePop. The FRAME_POP is always delivered, but often for the wrong method. For example, in the test log I see:

  NotifyFramePop called for method bar()I
  FRAME_POP event from method: LNotifyFramePopStressTest; foo()I

When calling NotifyFramePop, the test uses GetFrameLocation to get the name of the method that is currently at the top of the stack. When the FRAME_POP event arrives it should be the same method name, but often it is not.

Note it is important that the methods do very little in order to make it more likely that SuspendThread will be called at just the right time during method return to trigger the issue. It actually triggers a fairly high percent of the time in the above example. Larger method are less likely to see this issue.