I'm currently using atrace on Android to record and analyze the state of the OS during a video workload. Specifically, I'm monitoring the system's BufferQueue sizes throughout the execution. atrace logs the sizes of these buffers as they are queued/acquired over time.
However, in some of my traces, this leads to impossible situations. The C|171|SurfaceView|x lines denote 'x' as being the number of textures queued in the buffer. For example, sometimes during a single acquire, two buffers are removed instead of one (which should be impossible):
Binder_5-4526 ( 171) [002] ...1 1621.656462: tracing_mark_write: B|171|queueBuffer
Binder_5-4526 ( 171) [002] ...1 1621.656493: tracing_mark_write: C|171|SurfaceView|2
surfaceflinger-171 ( 171) [002] ...1 1621.664886: tracing_mark_write: B|171|acquireBuffer
surfaceflinger-171 ( 171) [002] ...1 1621.664978: tracing_mark_write: C|171|SurfaceView|0
In the BufferQueueConsumer.cpp file in Android's platform code (e.g., https://android.googlesource.com/platform/frameworks/native/+/android-5.0.1_r1/libs/gui/BufferQueueConsumer.cpp), check out the acquireBuffer function.
In certain situations (e.g., the buffer is out of date), the function may decide to drop a buffer from the queue. There is no atrace indication of this event happening, you will simply see the buffer's size jump from 2 to 0.
There's also potential for closely interleaved queueBuffer/acquireBuffer commands where they print some unexpected buffer size transitions.