Open andingv opened 2 months ago
A large timestamp shouldn't be a problem, but the data
pointer looks corrupted, which probably means ts
was corrupted as well. Possibly a double-free of the packet
object or something like it. What are the contents of *dtxb
in frame 2?
ok thank you, here you go:
(gdb) fr 2
#2 0x000055bed2bec9e7 in __dtx_send_later (ct=0x7fc6a401d5f0) at codec.c:3072
3072 codec.c: No such file or directory.
(gdb) p *dtxb
$1 = {ct = {tt_obj = {obj = {ref = 2, free_func = 0x55bed2be9390 <__dtx_free>, size = 416}, tt = 0x55bed2e53bc0 <codec_timers_thread>, next_check = {tv_sec = 0, tv_usec = 0}, last_run = {
tv_sec = 1713279718, tv_usec = 170421}}, next = {tv_sec = 1713279718, tv_usec = 170421}, timer_func = 0x55bed2bec4c0 <__dtx_send_later>}, lock = {__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, csh = 0x7fc73c089d90, ptime = 20,
tspp = 160, clockrate = 8000, call = 0x7fc6fc0105a0, packets = {head = 0x7fbfd406f820, tail = 0x7fbfeffbbd00, length = 7}, last_mp = {raw = {s = 0x0, len = 0}, fsin = {address = {
family = 0x55bed2e51b80 <__socket_families>, u = {ipv4 = {s_addr = 113162329}, ipv6 = {__in6_u = {__u6_addr8 = "Y\270\276\006", '\000' <repeats 11 times>, __u6_addr16 = {47193, 1726, 0, 0,
0, 0, 0, 0}, __u6_addr32 = {113162329, 0, 0, 0}}}}}, port = 26856}, tv = {tv_sec = 1713279718, tv_usec = 40418}, sfd = 0x7fc630056450, call = 0x7fc6fc0105a0, stream = 0x7fc71c0900d0,
media = 0x7fc66c0d0810, media_out = 0x7fc62c0db7b0, sink = {sink = 0x7fc6cc111080, handler = 0x55bed2e486d0 <__sh_noop_rtp>, kernel_output_idx = -1, rtcp_only = 0, transcoding = 1},
rtp = 0x7fc48c0df360, rtcp = 0x0, ssrc_in = 0x7fc69814a570, ssrc_out = 0x7fc69814cbf0, payload = {s = 0x0, len = 0}, packets_out = {head = 0x0, tail = 0x0, length = 0}, ptime = 0},
head_ts = 4715930405566051902, ssrc = 3270805003, start = 1713279718}
rtpengine version the issue has been seen with
mr10.5.1
Used distribution and its version
Ubuntu 18.04.6 LTS
Linux kernel version used
No response
CPU architecture issue was seen on (see
uname -m
)x86_64
Expected behaviour you didn't see
No response
Unexpected behaviour you saw
I am seeing a seldom crash, last week two hosts crashed independently.
Steps to reproduce the problem
Not sure, but there's one idea . Am I seeing it right that some endpoint is sending the RTP packet with huge
ts
causing this behavior? Program terminated with signal SIGSEGV, Segmentation fault.0 0x000055bed2c174a5 in decoder_input_data_ptime (dec=0x7fc6ec17e690, data=0xc0089a793fe274df, ts=4715930405566051902, ptime=ptime@entry=0x7fc7bb5f9288,
Additional program output to the terminal or logs illustrating the issue
something more: