[Bug 774600] mpegtsdemux: Pipeline hang on lossy transport stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774600

--- Comment #6 from minfrin at sharp.fm ---
Digging further, I am able to reproduce the hang using just the tsdemux element
alone, like this:

gst-launch-1.0 filesrc location=/mnt/stream/raw.ts ! progressreport
update-freq=5 ! tsdemux ! fakesink

When it hangs, the backtrace of all threads looks like this:

0:00:07.177036844 26676   0x19dac0 DEBUG                tsdemux
tsdemux.c:2562:gst_ts_demux_push_pending_data:<tsdemux0:subpicture_0_1d51>
stream:0x75b20750, pid:0x1d51 stream_type:6 state:0
^C
Program received signal SIGINT, Interrupt.
0x76bf5b80 in poll () at ../sysdeps/unix/syscall-template.S:81
81    ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) thread apply all backtrace

Thread 3 (Thread 0x75aff460 (LWP 26684)):
Cannot access memory at address 0x1
#0  0x76bf5b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x76d0a528 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (Thread 0x7645c460 (LWP 26683)):
#0  syscall () at ../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
#1  0x76d5443c in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2  0x76f30670 in gst_task_func (task=0x1a1828) at gsttask.c:319
#3  0x76f31e50 in default_func (tdata=0x19bac0, pool=0x38458) at
gsttaskpool.c:68
#4  0x76d3445c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0x76ff5210 (LWP 26676)):
Cannot access memory at address 0x1
#0  0x76bf5b80 in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x76d0a528 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) threads info
Undefined command: "threads".  Try "help".
(gdb) info threads
  Id   Target Id         Frame 
  3    Thread 0x75aff460 (LWP 26684) "gmain" 0x76bf5b80 in poll () at
../sysdeps/unix/syscall-template.S:81
  2    Thread 0x7645c460 (LWP 26683) "tsdemux0:sink" syscall () at
../ports/sysdeps/unix/sysv/linux/arm/syscall.S:37
* 1    Thread 0x76ff5210 (LWP 26676) "gst-launch-1.0" 0x76bf5b80 in poll () at
../sysdeps/unix/syscall-template.S:81

The second thread seems to be stuck with a task that has been paused, like so:

#2  0x76f30670 in gst_task_func (task=0x1a1828) at gsttask.c:319
319          GST_TASK_WAIT (task);
(gdb) print *task
$1 = {object = {object = {g_type_instance = {g_class = 0x3a528}, ref_count = 2,
qdata = 0x0}, lock = {p = 0x0, i = {0, 0}}, name = 0x75b00c98 "tsdemux0:sink",
parent = 0x0, flags = 0, control_bindings = 0x0, control_rate = 100000000, 
    last_sync = 18446744073709551615, _gst_reserved = 0x0}, state =
GST_TASK_PAUSED, cond = {p = 0x0, i = {1, 0}}, lock = 0x184474, func =
0x7671f5dc <mpegts_base_loop>, user_data = 0x18e188, notify = 0x0, running = 1,
thread = 0x19dac0, 
  priv = 0x1a1800, _gst_reserved = {0x0, 0x0, 0x0, 0x0}}

Does this code look right? We seem to start the task before unlocking
base->sinkpad, is this correct?

done:
  if (flush_event)
    gst_event_unref (flush_event);
  gst_pad_start_task (base->sinkpad, (GstTaskFunction) mpegts_base_loop, base,
      NULL);

  GST_PAD_STREAM_UNLOCK (base->sinkpad);
  return ret == GST_FLOW_OK;

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.