-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[multistream] Segmentation fault, re-negotation/DTLS alert race condition #2761
Comments
Thanks for the detailed report @cameronlucas3 |
Oops, I was inspecting the wrong file! My bad, sorry for the noise. |
I guess the obvious, and simplest, choice would be wrapping that simulcast traversal check in It might be better to extend the usage of that mutex to more parts of that request management, though, as just fixing it there may still result in some weird state in case conflict occurs (we start handling a new SDP, an alert wipes everything away, we then keep on handling the request anyway after the mutex is released). I'll have a look at the code to see if/where this can be done. |
@cameronlucas3 apologies if this took a while, but I had a stab at a few multistream issues so I addressed this too. Could you let me know if you can still replicate this, or if we can consider this fixed? |
I'll assume it's fixed. Please let us know if that's not the case. |
There appears to be a race condition that can occur when a client sends a new SDP, and then immediately closes it's peer connection (hang-up due to
DTLS alert
).This causes a segmentation fault, due to a null pointer access of
handle->pc
atjanus-gateway/janus.c
Line 1630 in e741411
I am able to reliably reproduce it, by adding a
sleep(1)
immediately before that loop. And then forcing our own web client to re-negotiate and close it's PeerConnection ~100ms later.Full stack trace from AddressSanitizer
The text was updated successfully, but these errors were encountered: