Possibly incorrect assertion on sequence: take_gil -> drop_gil -> drop_gil__return

[olumide-x]

I've been running per4m extensively on perf data sampled from a heavily multithreaded application that my team is developing and per4m consistently asserts on sequences take_gil -> drop_gil -> drop_gil__return, for example

       viztracer  5533 [003]  3220.317244274:         python:take_gil: (55fe99b0d01e)
       viztracer  5533 [003]  3220.317407813:         python:drop_gil: (55fe99b0cf20)
       viztracer  5533 [003]  3220.317412443: python:drop_gil__return: (55fe99b0cf20 <- 55fe99baaa9e)  # example 1
       viztracer  5533 [003]  3220.317419189:         python:take_gil: (55fe99b0d01e)
       viztracer  5533 [003]  3220.317422951:         python:drop_gil: (55fe99b0cf20)
       viztracer  5533 [003]  3220.317425869: python:drop_gil__return: (55fe99b0cf20 <- 55fe99baaa9e)  # example 1

Yet a read of the Python source shows that the function take_gil can call drop_gil and the function drop_gil returns to take_gil.

Is this a corner case that per4m does not anticipate?