-
Notifications
You must be signed in to change notification settings - Fork 619
Open
Labels
Description
OpenSIPS version you are running
OpenSIPS 3.4
Describe the bug
We experienced a production deadlock in OpenSIPS where UDP receiver processes became unresponsive, stuck in an infinite loop attempting to acquire a lock that was already held by the same execution path.
GDB backtrace:
#0 sched_yield () at ../sysdeps/unix/syscall-template.S:120
#1 _b2b_send_request (dlg=<optimized out>, req_data=0x7ffcdf9ccd50) at dlg.c:2379
hash_index = 23
local_index = 2257678
table = 0x7f87e2bebff8
[Attempting to acquire lock: get_lock(lock=0x7f87e2bec228)]
#2 _b2b_pass_request (msg=0x7f88e3605298, tuple=0x0, entity=0x0) at logic.c:1443
#3 b2b_pass_request (msg=<optimized out>) at logic.c:1885
#11 b2b_logic_notify_request (src=0, msg=0x7f88e3605298, key=0x7ffcdf9cddb0,
body=0x7ffcdf9cd630, extra_headers=0x7ffcdf9cd640, b2bl_key=0x7ffcdf9cddc0,
hash_index=<optimized out>, local_index=<optimized out>, flags=0) at logic.c:1824
[Lock ALREADY acquired at line 1483: B2BL_LOCK_GET(hash_index)]
[Lock still held when calling _b2b_pass_request at line 1835]
The Fix (?)
We modified
modules/b2b_logic/logic.c at line 1834 to release the lock before calling _b2b_pass_request() :
send_usual_request:
/* Release lock before calling _b2b_pass_request to avoid deadlock
* when _b2b_send_request tries to acquire the same lock */
if (locked) {
B2BL_LOCK_RELEASE(hash_index);
locked = 0;
}
if (_b2b_pass_request(msg, tuple, entity) < 0)
goto error;
I saw the same protection code used in other parts of opensips code so I gave it a try and the issue
seems to have been fixed. I can verify after 10days of production traffic.
Please verify that from your side also.
Thanks
Vasilios Tzanoudakis