Project

General

Profile

Bug #1898

segfault on startup (initial scan)

Added by Miro K. almost 11 years ago. Updated almost 11 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Crashes
Target version:
-
Start date:
2013-12-29
Due date:
% Done:

100%

Estimated time:
Found in version:
3.9.304~gc50b049
Affected Versions:

Description

Hi, I am having problem resulting in crashing of the tvheadend process. When I start the backend, it is doing the initial scan (I can see it over the browser) but once a client is connecting to it (xbmc pvr openelec@rspb) it is causing following crash:

Dec 29 19:03:58 tvhe tvheadend[26169]: subscription: 'initscan' subscribing to mux, weight: 2, adapter: '/dev/dvb/adapter3/frontend0', network: 'Astra_23_5E', mux: '11973V'
Dec 29 19:03:58 tvhe tvheadend[26169]: htsp: Got connection from 192.168.180.49
Dec 29 19:03:58 tvhe tvheadend[26169]: htsp: 192.168.180.49: Welcomed client software: XBMC Media Center (HTSPv8)
Dec 29 19:03:58 tvhe tvheadend[26169]: htsp: 192.168.180.49 [ XBMC Media Center ]: Disconnected
Dec 29 19:03:58 tvhe tvheadend[26169]: htsp: 192.168.180.49: Welcomed client software: XBMC Media Center (HTSPv8)
Dec 29 19:03:58 tvhe tvheadend[26169]: htsp: 192.168.180.49 [ XBMC Media Center ]: Disconnected
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: Signal: 11 in PRG: /usr/bin/tvheadend (3.9.304~gc50b049) [63d237a1720988789d505aacb4ad8f5638475a9f] CWD: /
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: Fault address 0x38 (Address not mapped)
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: Loaded libraries: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 /lib/x86_64-linux-gnu/libz.so.1 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 /usr/lib/liburiparser.so.1 /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 /usr/lib/x86_64-linux-gnu/libavcodec.so.53 /usr/lib/x86_64-linux-gnu/libavutil.so.51 /usr/lib/x86_64-linux-gnu/libavformat.so.53 /usr/lib/x86_64-linux-gnu/libswscale.so.2 /lib/x86_64-linux-gnu/librt.so.1 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libidn.so.11 /usr/lib/x86_64-linux-gnu/libssh2.so.1 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 /usr/lib/x86_64-linux-gnu/libgnutls.so.26 /lib/x86_64-linux-gnu/libgcrypt.so.11 /usr/lib/x86_64-linux-gnu/librtmp.so.0 /lib/x86_64-linux-gnu/libdbus-1.so.3 /usr/
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: Register dump [23]: 00007f9a38000088feff38332d2f373000000000006c2be00000000000000202000000000000000200007f9a380072c000000000ffffffff00000000006add1000007f9a380192c50000000000484003000000000000000000007f9a38007180000000000000000000007f9a380192c0000000000050535400007f9a3fdd2660000000000041f756000000000001020200000000000000330000000000000004000000000000000efffffffe7ffbfa170000000000000038
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: STACKTRACE
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/trap.c:143 0x42a546
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: ??:0 0x7f9a5f19f030
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/htsp_server.c:2160 0x41f756
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/tcp.c:624 0x40eca2
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/api/api_status.c:88 0x431063
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/webui/webui_api.c:43 0x448f59
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/http.c:348 0x40f8cd
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/http.c:379 0x40fcf3
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/http.c:457 0x40fe82
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/http.c:758 0x41036d
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/tcp.c:442 0x40e18e
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: /tvhe/tvheadend/src/wrappers.c:103 0x40c4f8
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: ??:0 0x7f9a5f196b50
Dec 29 19:03:58 tvhe kernel: [104205.098998] tcp_server_star[26376]: segfault at 38 ip 000000000041f756 sp 00007f9a3fdd2660 error 4 in tvheadend[400000+ae000]
Dec 29 19:03:58 tvhe tvheadend[26169]: CRASH: clone+0x6d  (/lib/x86_64-linux-gnu/libc.so.6)

Unfortunatelly it doesn't creates core dump. The initial scan takes on 3 sattelites really long and to reproduce the error sometimes I have to reboot the xbmc client, sometimes it comes along (running openelec 3.2.4 with TVHeadend HTSP Client 1.6.19)

Disabling the initial scan on all networks solves that issue for me.


Files

tvheadend (4.38 MB) tvheadend tvhe binary (Debian 3.2.51-1 x86_64) Miro K., 2013-12-30 00:06
core-tcp_server_star-11-105-44-7856-1388357669 (383 MB) core-tcp_server_star-11-105-44-7856-1388357669 core dump Miro K., 2013-12-30 00:16

History

#1

Updated by Miro K. almost 11 years ago

I updated to the latest version 3.9.305~g9a3ad1c as I noticed there is support for coredumps. So here is the coredump.

#2

Updated by Adam Sutton almost 11 years ago

  • Status changed from New to Accepted

Good to know that option actually works...

I'll see if I can look at that binary, not sure if my system will be compatible, might need to create a VM.

But I have some avenues to investigate.

Thanks.

#3

Updated by Adam Sutton almost 11 years ago

I can see the basic problem. I need to consider the best route to a fix.

Adam

#4

Updated by Miro K. almost 11 years ago

Great, that was quick, I do appreciate :)

I was trying to understend linux gdb so am I correct if this is only related to the opened browser (admin) connection to the backend, so if none browser will be connected this issue will not happen?

#5

Updated by Adam Sutton almost 11 years ago

Yes, the problem relates to what happens if a connection HTSP or HTTP is lost at the same instant that a web UI connection queries the status. I think due to the way the code is, it currently only affects if an HTSP connection is lost.

There is a very quick fix, which is to check for the NULL at the appropriate point and stop it from bombing out, but I think that will create a weird looking result in the UI status page (albeit for an instant). So I just want to think it through.

I might just push the quick fix and leave this open.

Adam

#6

Updated by Adam Sutton almost 11 years ago

  • Status changed from Accepted to Fixed
  • % Done changed from 0 to 100

Applied in changeset tvheadend|commit:dfde2ec4a2e66205b61831248700dcccdd8ca81e.

Also available in: Atom PDF