[1.x] segfault on opus_decode #3590
Description
What version of Janus is this happening on?
version based on master commit
302fab5
Have you tested a more recent version of Janus too?
no
Was this working before?
If you have information on a version/commit where the issue wasn't there (e.g., the result of a git bisect), please provide it here.
Is there a gdb or libasan trace of the issue?
(gdb) bt
#0 0x00007fa8e4ff6108 in opus_decoder_get_nb_samples () from /usr/lib/libopus.so.0
#1 0x00007fa8e4ff6285 in opus_decode () from /usr/lib/libopus.so.0
#2 0x00007fa8e5073b03 in janus_audiobridge_participant_thread (data=<optimized out>) at plugins/janus_audiobridge.c:9229
#3 0x00007fa8e629e5f0 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0x00007fa8e665a34f in start (p=0x7fa8e1df48e8) at src/thread/pthread_create.c:207
#5 0x00007fa8e665c965 in __clone () at src/thread/x86_64/clone.s:22
Backtrace stopped: frame did not save the PC
Additional context
I looked into dump with help of chatgpt and found out what decoder pointer is null at the moment of opus_decode
analysys from gpt:
Backtrace (trimmed):
#0 0x7fa8e4ff6108 in opus_decoder_get_nb_samples() from /usr/lib/libopus.so.0
#1 0x7fa8e4ff6285 in opus_decode() from /usr/lib/libopus.so.0
#2 0x7fa8e5073b03 in janus_audiobridge_participant_thread at plugins/janus_audiobridge.c:9229
Faulting instruction:
rip=0x7fa8e4ff6108: mov 0xc(%rax), %edx with rax=0x0 (NULL deref)
Call site in janus_audiobridge_participant_thread:
mov 0x208(%rbx), %rdi
call opus_decode@plt
Memory: [rbx+0x208] == 0x0 (decoder is NULL)
Call arguments at the site:
st (rdi) = NULL
data (rsi/r10) = 0x7fa8dab05c54
len (edx) = 47
frame_size (r8d) = 11520
decode_fec (r9d) = 0
No NULL check is visible before calling opus_decode in the relevant basic block.
Related participant fields at crash time:
[rbx+0x200] (likely opus_enc): 0x0
[rbx+0x208] (opus_dec): 0x0
[rbx+0x0a0] (jitter buffer ptr): 0x7fa8d2ce2fa0
[rbx+0x148] (mode/flag): 0x1
[rbx+0x218] (ssrc): 0x000b14e0
[rbx+0x21c] (seq): 0x000001cc
RTP header bytes at r14 (for the packet being processed):
90 6f 01 cd 00 0b 18 a0 0c f3 33 48 be de 00 01 10 d4 00 00 68 0b 55 05 fc d1 f7 4a 44 98 40 b5
Payload bytes at r10 (len=47):
68 0b 55 05 fc d1 f7 4a 44 98 40 b5 8b 95 38 22 fa 6d 21 51 2a 31 2f c2 5f f9 eb ca cd e8 1f c5 79 b1 94 68 98 10 00 93 bf 05 c8 4a 3a 11 01
this occurs very rare and on random customers(maybe 5 times during half of year)