Project

General

Profile

Bug #1211

Crash on IPTV H.264 feed; process still running, stacktrace does not complete

Added by Anonymous about 12 years ago. Updated about 12 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
IPTV
Target version:
-
Start date:
2012-09-06
Due date:
% Done:

0%

Estimated time:
Found in version:
3.1.605.g1d15f
Affected Versions:

Description

Got a similar crash as in bug #1188 - stacktrace does not complete, tvheadend does not exit.

Occurs when un/subscribing to an IPTV feed which is H.264 carried in MPEG2-TS.

Sep 6 12:45:15 videobox tvheadend[1824]: htsp: Got connection from 192.168.1.102
Sep 6 12:45:15 videobox tvheadend[1824]: htsp: 192.168.1.102: Welcomed client software: XBMC Media Center
Sep 6 12:45:19 videobox tvheadend[1824]: htsp: 192.168.1.102 [ XBMC Media Center ]: Disconnected
Sep 6 12:45:19 videobox tvheadend[1824]: subscription: "192.168.1.102 [ XBMC Media Center ]" unsubscribing from "TRUE"
Sep 6 12:45:20 videobox tvheadend[1824]: CRASH: Signal: 11 in PRG: /usr/local/bin/tvheadend (3.1.605.g1d15f) [eebccef52fab479b581979e70d33b0e12bd7f4fe] CWD: /
Sep 6 12:45:20 videobox tvheadend[1824]: CRASH: Fault address 0x18 (Address not mapped)
Sep 6 12:45:20 videobox tvheadend[1824]: CRASH: Loaded libraries: /lib/libssl.so.0.9.8 /lib/libcrypto.so.0.9.8 /lib/libz.so.1 /usr/lib/libavahi-common.so.3 /usr/lib/libavahi-client.so.3 /lib/librt.so.1 /lib/libdl.so.2 /lib/libpthread.so.0 /lib/libc.so.6 /lib/libdbus-1.so.3 /lib64/ld-linux-x86-64.so.2 /lib/libnss_compat.so.2 /lib/libnsl.so.1 /lib/libnss_nis.so.2 /lib/libnss_files.so.2
Sep 6 12:45:20 videobox tvheadend[1824]: CRASH: Register dump [23]: 00007f1cc67b2e40 00007f1cc67b2e48 00007f1cc67b2e90 81156667b844ee89 0000000002a7cfe0 0000000000000000 00007f1cc67b2e98 00007f1cc67b3668 00007f1cc67b2e40 0000000000000000 0000000000010020 0000000002a7cfc0 0000000000000000 0000000002a2aef0 00000000000af440 00007f1cacdf9ce0 00007f1cc64aa7dd 0000000000010202 0000000000000033 0000000000000004 000000000000000e fffffffe7ffbfa17 0000000000000018
Sep 6 12:45:20 videobox tvheadend[1824]: CRASH: STACKTRACE
Sep 6 12:45:21 videobox tvheadend[1824]: htsp: Got connection from 192.168.1.102
Sep 6 12:45:21 videobox tvheadend[1824]: htsp: 192.168.1.102: Welcomed client software: XBMC Media Center
Sep 6 12:45:21 videobox tvheadend[1824]: subscription: "192.168.1.102 [ XBMC Media Center ]" subscribing on "AV-IN", weight: 150, adapter: "eth2", network: "<N/A>", mux: "239.255.12.15", provider: "<N/A>", service: "<N/A>", quality: 100

History

#1

Updated by Adam Sutton about 12 years ago

  • Assignee deleted (Hein Rigolo)

Can you try and run this in gdb and get a full stack trace from there.

Adam

#2

Updated by Anonymous about 12 years ago

Adam Sutton wrote:

Can you try and run this in gdb and get a full stack trace from there.

Adam

Unfortunately we cannot run it in gdb. In the past, I believe the stacktrace was posted to syslog, but that doesn't seem to be happening now.

Here's another, similar crash; any further clues?

Sep 13 15:07:07 videobox tvheadend[1917]: subscription: "192.168.1.103 [ XBMC Media Center ]" unsubscribing from "TRUE"
Sep 13 15:07:07 videobox tvheadend[1917]: htsp: Got connection from 192.168.1.103
Sep 13 15:07:07 videobox tvheadend[1917]: htsp: 192.168.1.103: Welcomed client software: XBMC Media Center
Sep 13 15:07:08 videobox tvheadend[1917]: subscription: "192.168.1.103 [ XBMC Media Center ]" subscribing on "ES-Astro", weight: 150, adapter: "5 Astro 91.4E No. 1", network: "MEASAT Malaysia", mux: "MEASAT Malaysia: 11,482,000 kHz Vertical (Default (Port 0, Universal LNB))", provider: "Astro", service: "ES", quality: 100
Sep 13 15:07:08 videobox tvheadend[1917]: cwc: Obtained key for service "ES" in 54 ms, from 127.0.0.1:10006
Sep 13 15:07:12 videobox tvheadend[1917]: CRASH: Signal: 11 in PRG: /usr/local/bin/tvheadend (3.1.605.g1d15f) [eebccef52fab479b581979e70d33b0e12bd7f4fe] CWD: /
Sep 13 15:07:12 videobox tvheadend[1917]: CRASH: Fault address 0x7f004555526c (Address not mapped)
Sep 13 15:07:12 videobox tvheadend[1917]: CRASH: Loaded libraries: /lib/libssl.so.0.9.8 /lib/libcrypto.so.0.9.8 /lib/libz.so.1 /usr/lib/libavahi-common.so.3 /usr/lib/libavahi-client.so.3 /lib/librt.so.1 /lib/libdl.so.2 /lib/libpthread.so.0 /lib/libc.so.6 /lib/libdbus-1.so.3 /lib64/ld-linux-x86-64.so.2 /lib/libnss_compat.so.2 /lib/libnsl.so.1 /lib/libnss_nis.so.2 /lib/libnss_files.so.2
Sep 13 15:07:12 videobox tvheadend[1917]: CRASH: Register dump [23]: 00007f8a7d592e40 00007f8a7d592e48 00007f8a7d592e90 00000000000028e0 0000000001d4b390 00007f0045555254 00007f8a7d592e98 00007f8a7d592e98 00007f8a7d592e40 0000000000000000 0000000000010020 0000000001d4b370 0000000001cbf1d0 0000000001c690b0 0000000000000021 00007f8a60df9ce0 00007f8a7d28a7dd 0000000000010202 0000000000000033 0000000000000004 000000000000000e fffffffe7ffbfa17 00007f004555526c
Sep 13 15:07:12 videobox tvheadend[1917]: CRASH: STACKTRACE

#3

Updated by Adam Sutton about 12 years ago

  • Status changed from New to Need feedback

Without a proper (gdb) stack trace its going to be very difficult even begin to understand where the fault might lie. I don't have access to an IPTV stream to even test with.

The stacktrace from within TVH is unreliable and doesn't always work. As you are seeing here.

Why can't you run under gdb? Or at the very least enable coredumps so that you can post analyse with gdb?

Adam

#4

Updated by Anonymous about 12 years ago

Adam Sutton wrote:

Without a proper (gdb) stack trace its going to be very difficult even begin to understand where the fault might lie. I don't have access to an IPTV stream to even test with.

The stacktrace from within TVH is unreliable and doesn't always work. As you are seeing here.

Why can't you run under gdb? Or at the very least enable coredumps so that you can post analyse with gdb?

Adam

We're driving a number of monitors with tvheadend at a sport pub. The crash seems random, but I can try to reproduce it running under gdb during off-hours.

In the meantime, can you tell me how to enable coredumps?

Thanks,

Tom

#5

Updated by Adam Sutton about 12 years ago

Yeah just do "ulimit -c unlimited" that will enable unlimited core dumps in the current session. If you need to make it permanent you'd need to stick it in a user/system profile config file.

If you're running tvheadend from an init script etc.. you could stick that command in there.

Note: by default coredumps will simply be output to a file core in the local directory (so not sure where that will be exactly if you run from init as a daemon) and if you re-start the next crash will overwrite etc..

Adam

#6

Updated by Adam Sutton about 12 years ago

Tom,

Any update on this? It's been a while since the last update so I'm inclined to close.

Adam

#7

Updated by Anonymous about 12 years ago

Hi Adam,

We haven't seen the issue resurface, feel free to close.

Thanks,

Tom

#8

Updated by Adam Sutton about 12 years ago

  • Status changed from Need feedback to Invalid

Closed at user request.

Adam

Also available in: Atom PDF