imagine having a pipeline like:

v4l2src ! queue leaky=1 max-size-buffers=15 ! xvimagesink

running on a resource limmited device. The v4l2src captures at a rate, that xvimagesink can handle always (e.g. on high system load). What I observe in this scenario is that the loop_function that runs in the queue.src task is called just once (the initial frame). Later the v4l2src.src task runs and pushes buffers on the queue. The queue reports that it is full and drops (leaking). Even though that buffers are available (and thus the condition that the v4l2src.src task waits on gets triggered) the queue does not push out any buffers.

When I limmit the number of frames captured (num-buffers property), I can see that once the v4l2src stops capturing, the queue empties.

Unfortunately I have a hard time to reproduce this on an x86 system. I tried to run this with no luck:
GST_DEBUG="xvimagesink:3,queue*:4" nice -n19 gst-launch-0.10 -t videotestsrc is-live=true ! video/x-raw-yuv,width=6400,height=4800,framerate='(fraction)'30/1 ! queue leaky=1 max-size-buffers=15 max-size-time=0 max-size-bytes=0 ! videoscale ! video/x-raw-yuv,width=800,height=600,framerate='(fraction)'30/1 ! xvimagesink sync=false qos=false

attached is the log of the og running this pipeline on the embedded device:
GST_DEBUG="xvimagesink:3,queue*:4,task:4" gst-launch-0.10 v4l2src num-buffers=10 ! video/x-raw-yuv,width=176,height=144,framerate='(fraction)'15/1 ! queue leaky=1 max-size-buffers=5 max-size-time=0 max-size-bytes=0 ! xvimagesink sync=false qos=false

Please note that I modified the debug output slighly (change levels and added log statements).