[gstreamer-bugs] [Bug 569437] New: mpegtsparse: flow error or crashes while dynamicly changing program-numbers property

[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=569437

  GStreamer | gst-plugins-bad | Ver: 0.10.10
           Summary: mpegtsparse: flow error or crashes while dynamicly
                    changing program-numbers property
           Product: GStreamer
           Version: 0.10.10
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: mutex at runbox.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Please describe the problem:
See the following python program which dynamicly change the mpegtsparse's
"program-numbers" property.

This dynamic change is not working well : there is sometime a
"GST_FLOW_NOT_LINKED" error while the new pad is added (when new program entry
is added to the property) and rarely a segmentation fault while removing a pad
(when a program is removed from the property).

Steps to reproduce:
See the attached python sample program. 
This sample program reads a MPTS stream from an UDP multicast address (you can
use vlc to stream a MPTS file as a source)

Actual results:
-> many time the sample program is working well
-> but after a while, there is a GST_FLOW_NOT_LINKED error or a segmentation
fault

Expected results:


Does this happen every time?


Other information:
The segmentation is rare so here is a stack trace obtained using gdb:
$ gdb --args python test_tsparse.py
register program 6905 counter: 1
pad added
linking
linked
[New Thread 0xb64ffb90 (LWP 14586)]
[Thread 0xb64ffb90 (LWP 14586) exited]
unregister program 6905
pad removed
[....]
register program 6905 counter:28
pad added
linking
linked
[New Thread 0xb64ffb90 (LWP 14587)]
[Thread 0xb64ffb90 (LWP 14587) exited]
unregister program 6905
pad removed

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb76b8b90 (LWP 14569)]
mpegts_parse_push (parse=0x8441800, packet=0xb76b8040, section=0x0)
    at mpegtsparse.c:676
676           pad_pids = tspad->program->streams;
(gdb) bt
#0  mpegts_parse_push (parse=0x8441800, packet=0xb76b8040, section=0x0)
    at mpegtsparse.c:676
#1  0xb775b280 in mpegts_parse_chain (pad=0x8416240, buf=0xb5bc56f0)
    at mpegtsparse.c:1220
#2  0xb7d13029 in gst_pad_chain_unchecked (pad=0x8416240, buffer=0xb5bc56f0)
    at gstpad.c:3877
#3  0xb7d1426a in gst_pad_push (pad=0x8416180, buffer=0xb5bc56f0)
    at gstpad.c:4045
#4  0xb7781a72 in gst_queue_loop (pad=0x8416180) at gstqueue.c:1047
#5  0xb7d33613 in gst_task_func (task=0x8443008, tclass=0x82fc1a0)
    at gsttask.c:192
#6  0xb7ad16c6 in ?? () from /usr/lib/libglib-2.0.so.0
#7  0xb7ad002f in ?? () from /usr/lib/libglib-2.0.so.0
#8  0xb804b50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#9  0xb7f997ee in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) print tspad->program
$1 = (MpegTSParseProgram *) 0x30657372
(gdb) print tspad->program->streams
Cannot access memory at address 0x3065737e


In fact, I suppose this bug is due to concurrent accesses to the element data
(MpegTSParse->programs) between the task thread and the application thread
(trought the set_property).

I am working on a patch...


-- 
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=569437.