Project

General

Profile

Actions

Bug #5492

closed

Crash after mutex magic-error

Added by Flole Systems over 6 years ago. Updated about 6 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2019-01-11
Due date:
% Done:

100%

Estimated time:
Found in version:
4.3-1718~g8e0dd2bee
Affected Versions:

Description

I think I just had a mutex magic-error which caused a crash:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
120     ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory
[Current thread is 1 (Thread 0x7fb9c5eeb700 (LWP 19048))]
(gdb) bt
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120
#1  0x00007fb9d276d4d3 in _IO_vfprintf_internal (s=s@entry=0x7fb9c5eea2e0, format=format@entry=0x55a5fc5aa5a0 "mutex %p locked in: %s:%i (thread %ld)\n",
    ap=ap@entry=0x7fb9c5eea488) at vfprintf.c:1643
#2  0x00007fb9d2798910 in _IO_vsnprintf (string=0x7fb9c5eea4a0 "mutex 0x55a600068640 locked in: tsdemux.c:265)\n", maxlen=<optimized out>,
    format=0x55a5fc5aa5a0 "mutex %p locked in: %s:%i (thread %ld)\n", args=0x7fb9c5eea488) at vsnprintf.c:114
#3  0x000055a5fb5fe591 in htsbuf_vqprintf (hq=0x7fb9c5eea640, fmt=0x55a5fc5aa5a0 "mutex %p locked in: %s:%i (thread %ld)\n", ap0=0x7fb9c5eea530)
    at src/htsbuf.c:258
#4  0x000055a5fb5fe7bc in htsbuf_qprintf (hq=0x7fb9c5eea640, fmt=0x55a5fc5aa5a0 "mutex %p locked in: %s:%i (thread %ld)\n") at src/htsbuf.c:301
#5  0x000055a5fb5aa873 in tvh_thread_mutex_failed (mutex=0x55a600068640, reason=0x55a5fc5aa4df "magic",
    filename=0x55a5fc676b80 "src/input/mpegts/tsdemux.c", lineno=265) at src/tvh_thread.c:480
#6  0x000055a5fb5a9ca1 in tvh_mutex_check_magic (mutex=0x55a600068640, filename=0x55a5fc676b80 "src/input/mpegts/tsdemux.c", lineno=265)
    at src/tvh_thread.c:148
#7  0x000055a5fb5aa15b in tvh__mutex_lock (mutex=0x55a600068640, filename=0x55a5fc676b80 "src/input/mpegts/tsdemux.c", lineno=265) at src/tvh_thread.c:252
#8  0x000055a5fb6bbc68 in ts_recv_raw (t=0x55a600068450, tspos=20829924172, tsb=0x55a60019e179 "G@\021\025", len=188) at src/input/mpegts/tsdemux.c:265
#9  0x000055a5fb6b84ec in mpegts_input_process (mi=0x55a600571b70, mpkt=0x55a60019d420) at src/input/mpegts/mpegts_input.c:1519
#10 0x000055a5fb6b91de in mpegts_input_thread (p=0x55a600571b70) at src/input/mpegts/mpegts_input.c:1746
#11 0x000055a5fb5a9ac8 in thread_wrapper (p=0x55a6006461f0) at src/tvh_thread.c:91
#12 0x00007fb9d3dad6db in start_thread (arg=0x7fb9c5eeb700) at pthread_create.c:463
#13 0x00007fb9d283188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Also if the magic check really failed, is it possible to look what's written into the mutex? Maybe it becomes more clear where the memory corruption is coming from.

Actions

Also available in: Atom PDF