You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered a stack where sctp_free_assoc tries to acquire inp->inp_mtx even though it is called from sctp_close which already holds that lock. Since usrsctplib does not use recursive mutexes, this causes a deadlock.
This happened while the usrsctplib recv_callback was being invoked, which may be the cause of the problem.
Excerpted gdb info:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0xffffb0ab8020 (LWP 2195041) "crash_repro" futex_wait (private=0, expected=2, futex_word=0xaaaad6579568)
at ../sysdeps/nptl/futex-internal.h:146
12 Thread 0xffffaa6cf120 (LWP 2198629) "crash_repro" futex_wait (private=0, expected=2, futex_word=0xaaaad657e290)
at ../sysdeps/nptl/futex-internal.h:146
(gdb) bt
#0 futex_wait (private=0, expected=2, futex_word=0xaaaad6579568) at ../sysdeps/nptl/futex-internal.h:146
#1 __GI___lll_lock_wait (futex=futex@entry=0xaaaad6579568, private=private@entry=0) at ./nptl/lowlevellock.c:49
#2 0x0000ffffb081070c in lll_mutex_lock_optimized (mutex=0xaaaad6579568) at ./nptl/pthread_mutex_lock.c:48
#3 ___pthread_mutex_lock (mutex=mutex@entry=0xaaaad6579568) at ./nptl/pthread_mutex_lock.c:93
#4 0x0000ffffb0a3e38c in sctp_free_assoc (inp=inp@entry=0xaaaad65791c0, stcb=stcb@entry=0xaaaad657da70, from_inpcbfree=from_inpcbfree@entry=2,
from_location=from_location@entry=536870920) at ../../usrsctplib/netinet/sctp_pcb.c:5522
#5 0x0000ffffb0a40d8c in sctp_inpcb_free (inp=inp@entry=0xaaaad65791c0, immediate=immediate@entry=1, from=from@entry=1)
at ../../usrsctplib/netinet/sctp_pcb.c:4116
#6 0x0000ffffb0a4855c in sctp_close (so=so@entry=0xaaaad657adf0) at ../../usrsctplib/netinet/sctp_usrreq.c:891
#7 0x0000ffffb09f3aa0 in sofree (so=0xaaaad657adf0) at ../../usrsctplib/user_socket.c:287
#8 0x0000ffffb09f7b80 in usrsctp_close (so=<optimized out>) at ../../usrsctplib/user_socket.c:2005
#9 0x0000aaaac3cf20f8 in close_socket (o=0xffff9400f460) at crash_repro.c:164
Actually unfortunately it looks like this was a consequence of #710 -- unexpectedly, it looks like the library depends on the socket's reference count not going to zero during sctp_common_input_processing.
I encountered a stack where
sctp_free_assoc
tries to acquireinp->inp_mtx
even though it is called fromsctp_close
which already holds that lock. Since usrsctplib does not use recursive mutexes, this causes a deadlock.This happened while the usrsctplib recv_callback was being invoked, which may be the cause of the problem.
Excerpted gdb info:
The text was updated successfully, but these errors were encountered: