[gstreamer-bugs] [Bug 571825] unit test failures on gentoo (gcc 4.3.3)

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=571825

  GStreamer | gstreamer (core) | Ver: 0.10.22




------- Comment #10 from Tim-Philipp Müller  2009-04-17 14:08 UTC -------
Thanks for the logs!

I had a look at the test_buffer_probe_n_times test failure yesterday. The
problem is that fakesink does not push the latency event it receives via the
send_event vfunc upstream, so the event probe only ever sees the newsegment and
eos events, but no latency event.

So the sequence should be:
A gstevent.c:1062:gst_event_new_latency: creating latency event
0:00:00.000000000
B gstevent.c:267:gst_event_new: creating new event 0x809d0a0 latency 289
C gstelement.c:1384:gst_element_send_event: send latency event on element
pipeline0
D gstbin.c:2462:gst_bin_send_event:<pipeline0> Sending latency event to sink
children
E gstelement.c:1384:gst_element_send_event: send latency event on element
fakesink0
F gstbasesink.c:3586:gst_base_sink_send_event:<fakesink0> latency set to
0:00:00.000000000
G gstpad.c:4521:gst_pad_push_event:<fakesink0:sink> event: latency
H check gst/gstutils.c:63:event_probe:<fakesink0:sink> event probe 2 [latency]
I gstpad.c:4573:gst_pad_push_event:<fakesink0:sink> sending event latency to
peerpad <fakesrc0:src>
J gstpad.c:4698:gst_pad_send_event:<fakesrc0:src> have event type latency
K gstevent.c:223:gst_event_finalize: freeing event 0x809d0a0 type latency

But steps G-J are missing in your case.

How or why that would happen, I don't know. My best guess would be that, for
some reason, ../../plugins/elements/.libs/libgstcoreelements.so does not
link/use the libgstbase-0.10.so in the source tree, but an older installed
version from elsewhere. I can't reproduce the problem myself though, it seems
to use the internal lib just fine for me (libtool 2.2.4, automake 1.10.1,
autoconf 2.61).


Maybe you could add a g_print ("forward latency event %d\n", forward); in
libs/gst/base/gstbasesink.c line 3592 (in the GST_EVENT_LATENCY case in
gst_base_sink_send_event), to see whether (a) the locally built
libgstbase-0.10.so is used, and (b) whether it tries to forwarded the event or
not.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=571825.