> Initializing GStreamer Core Library version 0.10.19

Does this still happen with / also apply to the latest release (0.10.25) or git?

Yes, with GIT it still fails.

Running suite(s): queue
20%: Checks: 5, Failures: 3, Errors: 1
elements/queue.c:172:F:general:test_non_leaky_overrun:0: Assertion 'overrun_count == 1' failed
elements/queue.c:228:E:general:test_leaky_upstream:0: (after this point) Test timeout expired
elements/queue.c:285:F:general:test_leaky_downstream:0: Assertion 'underrun_count == 0' failed
elements/queue.c:373:F:general:test_time_level:0: Failure 'time != 2 * GST_SECOND' occured
Running suite(s): queue

I was looking at the queue test recently, while I tried to write the
jitterbuffer test and I think the queue test is either flawed or super smart.
In the latter case it could get some comments to explain how it works.

It works reliably on a single core. The reporter was testing on multicore
according to discussion on irc.

hi ,

i tried to debug and do some experiment, did some changes and with this test cases are passing . want to know ur comments on the same :

static void
queue_underrun (GstElement * queue, gpointer user_data)
{
  GST_DEBUG ("queue underrun");
  g_mutex_lock (check_mutex);
  underrun_count++;
  g_cond_signal (check_cond);
  g_mutex_unlock (check_mutex);
  //change 1 added sleep so that this thread suspends for 2 sec
  sleep(2);
}


/* set queue size to 2 buffers
 * push 2 buffers
 * check over/underuns
 * push 1 more buffer
 * check over/underuns again
 */
GST_START_TEST (test_non_leaky_overrun)
{
  GstElement *queue;
  GstBuffer *buffer1, *buffer2, *buffer3;

  queue = setup_queue ();
  mysrcpad = gst_check_setup_src_pad (queue, &srctemplate, NULL);
  mysinkpad = gst_check_setup_sink_pad (queue, &sinktemplate, NULL);
  gst_pad_set_active (mysrcpad, TRUE);
  g_object_set (G_OBJECT (queue), "max-size-buffers", 2, NULL);

  GST_DEBUG ("starting");

  //fail_unless (gst_element_set_state (queue,
  //        GST_STATE_PLAYING) == GST_STATE_CHANGE_SUCCESS,
  //    "could not set to playing");
//change 2 : making this thread to wait for cond signal
    g_mutex_lock (check_mutex);
    fail_unless (gst_element_set_state (queue,
            GST_STATE_PLAYING) == GST_STATE_CHANGE_SUCCESS,
        "could not set to playing");
    TEST_ASSERT_FAIL
    g_cond_wait (check_cond, check_mutex);
    g_mutex_unlock (check_mutex);
    //change 3 : making undercount value zero
    underrun_count = 0;


  buffer1 = gst_buffer_new_and_alloc (4);
  ASSERT_BUFFER_REFCOUNT (buffer1, "buffer", 1);
  /* pushing gives away my reference ... */
  gst_pad_push (mysrcpad, buffer1);

  GST_DEBUG ("added 1st");
  fail_unless (overrun_count == 0);
  fail_unless (underrun_count == 0);

  buffer2 = gst_buffer_new_and_alloc (4);
  ASSERT_BUFFER_REFCOUNT (buffer2, "buffer", 1);
  /* pushing gives away my reference ... */
  gst_pad_push (mysrcpad, buffer2);

  GST_DEBUG ("added 2nd");
  fail_unless (overrun_count == 0);
  fail_unless (underrun_count == 0);

  buffer3 = gst_buffer_new_and_alloc (4);
  ASSERT_BUFFER_REFCOUNT (buffer3, "buffer", 1);
  /* pushing gives away my reference ... */
  gst_pad_push (mysrcpad, buffer3);

  GST_DEBUG ("stopping");

  fail_unless (overrun_count == 1);
  fail_unless (underrun_count == 0);

  /* cleanup */
  gst_pad_set_active (mysrcpad, FALSE);
  gst_check_teardown_src_pad (queue);
  gst_check_teardown_sink_pad (queue);
  cleanup_queue (queue);
}

GST_END_TEST;

added the changes in comments with change : 1/2/3 
is this approach cprrect or am i doing anything wrong ?

still one open question why the underrun callback is getting called in this test case ?

Created attachment 168200 [details] [review]
Fixes races in queue unit tests

I rewrote the queue unit tests, I think they are race free now.

commit 63c0e75e15f5ef83ec454a6a9760328665d26ba4
Author: Jonas Holmberg <jonas.holmberg@axis.com>
Date:   Wed Aug 18 15:12:45 2010 +0200

    queue: fixed racy unit tests
    
    Fixes #600004

commit e3dbe65314e720edadbd28a6defdce258c1ebc3a
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Aug 18 15:31:09 2010 +0200

    check: enable queue test again