Bug #1666
Deadlock in dvb_adapter_stop
100%
Description
global_mutex is held by thread 23, so it may not be possible to stop the adapter running on thread 19, which is currently blocked whilst it tries to claim that same mutex:
Thread 19 (Thread 0x7f495b7fe700 (LWP 4437)):
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1 0x00007f4995040065 in _L_lock_858 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2 0x00007f499503feba in __pthread_mutex_lock (mutex=0x6a95e0 <global_lock>) at pthread_mutex_lock.c:61
#3 0x000000000045466a in dvb_adapter_input_dvr (aux=0x15ff640) at src/dvb/dvb_adapter.c:1065
#4 0x00007f499503de9a in start_thread (arg=0x7f495b7fe700) at pthread_create.c:308
#5 0x00007f4994a6ecbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6 0x0000000000000000 in ?? ()
src/dvb/dvb_adapter.c (dvb_adapter_input_dvr), line 1065, is the mutex_lock here:
epoll_ctl(efd, EPOLL_CTL_ADD, fd, &ev);
/* Note: table handlers must be installed with global lock */
pthread_mutex_lock(&global_lock);
tda->tda_locked = locked = 1;
delay = -1;
Thread 23 (Thread 0x7f49837fe700 (LWP 3146)):
#0 0x00007f499503f148 in pthread_join (threadid=139953044449024, thread_return=thread_return@entry=0x0) at pthread_join.c:89
#1 0x0000000000456ffd in dvb_adapter_stop (tda=tda@entry=0x15ff640, opt=opt@entry=2) at src/dvb/dvb_adapter.c:734
---Type <return> to continue, or q <return> to quit---
#2 0x00000000004517ae in dvb_fe_stop (tdmi=<optimised out>, retune=retune@entry=1) at src/dvb/dvb_fe.c:289
#3 0x0000000000451a8f in dvb_fe_tune (tdmi=0x1c41fe0, reason=reason@entry=0x483e40 "Transport start") at src/dvb/dvb_fe.c:444
#4 0x000000000045ab45 in dvb_service_start (t=0x1c43dc0, weight=0, force_start=0) at src/dvb/dvb_service.c:89
#5 0x00000000004198f9 in service_start (t=0x1c43dc0, weight=0, force_start=0) at src/service.c:208
#6 0x000000000041ae5c in service_find (ch=<optimised out>, weight=150, loginfo=loginfo@entry=0x7f49837fda20 "Subscription \"127.0.0.1 [ xbmc | XBMC Media Center ]\"", errorp=errorp@entry=0x7f49837fda1c, skip=0x7f49837fd980,
skip@entry=0x0) at src/service.c:387
#7 0x0000000000418869 in subscription_reschedule () at src/subscriptions.c:186
#8 0x0000000000418cc3 in subscription_create_from_channel (ch=ch@entry=0x168b5a0, weight=weight@entry=150, name=<optimised out>, st=st@entry=0x7f49780023b0, flags=flags@entry=0, hostname=<optimised out>,
username=0x7f4978001090 "xbmc", client=0x7f4978000d30 "XBMC Media Center") at src/subscriptions.c:384
#9 0x00000000004214d5 in htsp_method_subscribe (htsp=0x7f49837fdc50, in=<optimised out>) at src/htsp_server.c:1334
#10 0x000000000042505f in htsp_read_loop (htsp=0x7f49837fdc50) at src/htsp_server.c:1817
#11 htsp_serve (fd=13, opaque=<optimised out>, source=<optimised out>, self=<optimised out>) at src/htsp_server.c:1944
#12 0x000000000040951f in tcp_server_start (aux=0x7f49740008c0) at src/tcp.c:428
#13 0x00007f499503de9a in start_thread (arg=0x7f49837fe700) at pthread_create.c:308
#14 0x00007f4994a6ecbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x0000000000000000 in ?? ()
History
Updated by Adam Sutton over 11 years ago
Updated by Thanks I was aware the bug existed just been stuck for time of late. But this will help.
Adam
Updated by Adam Sutton over 11 years ago
try this branch: https://github.com/adamsutton/tvheadend/tree/issue/1666
It contains a possible reworking, though its currently untested (my system is in use).
Adam
Updated by Anonymous over 11 years ago
The patch appears to work OK; I haven't been able to cause that particular deadlock.
I had to change the re-arm timer from 10ms to 100ms in dvb/dvb_fe.c::dvb_fe_monitor, otherwise tvheadend would get stuck in a tight loop more-or-less continually calling db_fe_monitor. Other threads would be starved access to the global_lock mutex causing the web-interface and channel changing to not respond.
Updated by Adam Sutton over 11 years ago
Yeah I was a bit worried that might be too tight, hopefully 100ms won't be that noticeable. There were some bugs in an earlier version which caused it to do horrible things, so do check you have the latest version from the branch. (I think I force pushed it over the top).
Adam
Updated by Adam Sutton over 11 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset tvheadend|commit:d75b99a610f4cab4c703f2f2dda5f84141524202.