Project

General

Profile

Bug #3479

Tvheadend crashes when stopping recording

Added by Uli Bruckdorfer almost 9 years ago. Updated almost 9 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
PVR / DVR
Target version:
-
Start date:
2016-01-05
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1-1315
Affected Versions:

Description

As prior described and sadly rejected in Bug #3401 (Rejected): Tvheadend crashes when stopping recording.

On commit bdda940cafea2fc322b3548aef16144fdb9ffb3b the Problem exists:
When starting a recording (by hand or via timer) all is working fine, current recording is shown in list an the .ts file is written to disk constantly. But when i click on "stop recording" or "abort recording", the frontend will show "wait while..." for about 10 sec. After that i can not do anything in the frontend, it does not react any more.
The record-file is still be written.


Files

gdb.txt (48.7 KB) gdb.txt Uli Bruckdorfer, 2016-01-05 20:21
gdb.txt (49.8 KB) gdb.txt Uli Bruckdorfer, 2016-01-21 17:11

History

#1

Updated by Jaroslav Kysela almost 9 years ago

It looks like a stall in ioctl() - 0x00000000004d1672 in linuxdvb_frontend_monitor (aux=0x1b7a6a0) at src/input/mpegts/linuxdvb/linuxdvb_frontend.c:824 :

824)      if (!ioctl(lfe->lfe_fe_fd, FE_READ_SNR, &u16)) {

Blame your driver.

#2

Updated by Uli Bruckdorfer almost 9 years ago

Jaroslav Kysela wrote:

It looks like a stall in ioctl() - 0x00000000004d1672 in linuxdvb_frontend_monitor (aux=0x1b7a6a0) at src/input/mpegts/linuxdvb/linuxdvb_frontend.c:824 :

[...]

Blame your driver.

Ok, but it would take some time to fix this driver at the kernel sources. Do you think it would be possible to do a short workaround at my side? As far as i have seen the only time the ioctl with FE_READ_SNR is called at linuxdvb_frontend.c.
Would it work if i comment the if state and do mmi->tii_stats.snr_scale = SIGNAL_STATUS_SCALE_UNKNOWN; instead?

#3

Updated by Uli Bruckdorfer almost 9 years ago

I have tested with an other driver (https://github.com/DigitalDevices/dddvb/releases) with the result that everything is working except the Signal Strenght is always shown with 100% on the web interface. Multiple Channels can be watched live via streaming, there a no problems. But the described crash when stopping a record via the web interface or automaticaly by the time still exists.
By the way, there are no problems when i use other tools like gnutTv or kaffein, so i will not blame the driver.
I did some more debugging with gdb and found
(gdb) bt
#0 0x00007f616db47797 in ioctl () from /usr/lib/libc.so.6
#1 0x00000000004d1512 in linuxdvb_frontend_monitor (aux=0x230b5e0)
at src/input/mpegts/linuxdvb/linuxdvb_frontend.c:900
#2 0x000000000040ce14 in mainloop () at src/main.c:557
#3 main (argc=<optimized out>, argv=<optimized out>;) at src/main.c:1112
(gdb) continue
Continuing.
[New Thread 0x7f61177fe700 (LWP 739)]
[New Thread 0x7f6145ffb700 (LWP 740)]
[New Thread 0x7f6144ff9700 (LWP 741)]

// Here stop was pressed, now program hang at _lll_lock_wait

Program received signal SIGINT, Interrupt.
0x00007f616e31fcfc in __lll_lock_wait () from /usr/lib/libpthread.so.0
(gdb) bt
#0 0x00007f616e31fcfc in __lll_lock_wait () from /usr/lib/libpthread.so.0
#1 0x00007f616e31b8a0 in __pthread_mutex_cond_lock ()
from /usr/lib/libpthread.so.0
#2 0x00007f616e31d4fa in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /usr/lib/libpthread.so.0
#3 0x000000000040ce94 in mainloop () at src/main.c:571
#4 main (argc=<optimized out>, argv=<optimized out>;) at src/main.c:1112

i have a core-dump file for this state, but its quite big to attach. If you want to take a look let me know so i will search a possibility to share the coredump with you.

#4

Updated by Uli Bruckdorfer almost 9 years ago

#5

Updated by Jaroslav Kysela almost 9 years ago

Thread 1 (Thread 0x7f162f3e9b40 (LWP 5010)):
#0  0x00007f162b12b797 in ioctl () from /usr/lib/libc.so.6

The tvh main thread is stuck in ioctl() - this fcn locks the mutex global_lock, so all other threads start waiting for this lock release. Really a driver issue, the ioctl should not block. Other apps probably uses a different device I/O sequences which don't trigger this issue. You may just comment out this ioctl.

#6

Updated by Jaroslav Kysela almost 9 years ago

And don't forget to report this to the authors of the driver.

Also available in: Atom PDF