I'm working on a Python wrapper for launching SIPp scenarios and ran into a weird issue when launching the default uac scen and providing an invalid remote address:
The following should expose the issue:
sipp 99.99.99.99:5060 -sn uac
You can now pass q to stdin twice before the curses ui stops updating. Passing q a 3rd time triggers a message similar to the following:
Last Error: Aborted call with Call-ID '23-20007@fe80::215:ff:fee3:e25c%w...
At this point the process does not respond to SIGUSR1 or any further qs passed to stdin. Passing the -timeout 1s arg seems to make no difference.
NOTE: if I pass -recv_timeout 100 (or any shorter ms value) the process does in fact terminate when signaled as expected but only after a timeout event has taken place. However, if I pass a longer value, say 10 secs -recv_timeout 10000, then the same problem can be triggered if type the 3 qs prior to the timeout of the first call attempt.
It looks like the call to main_scenario->stats->GetStat(CStat::CPT_C_CurrentCall) returns the number of active calls counter (also what the curses ui reports)? The loop doesn't terminate when the bug is triggered because this counter seems to never be decremented/reset.
Oddly, after a call timeout it does seem to have been decremented elsewhere and eventually decreases to 0 after a couple more loops in traffic_thread().
wdoekes
commented
3 years ago
I'm working on a Python wrapper for launching SIPp scenarios and ran into a weird issue when launching the default uac scen and providing an invalid remote address:
The following should expose the issue:
You can now pass
qto stdin twice before the curses ui stops updating. Passingqa 3rd time triggers a message similar to the following:Last Error: Aborted call with Call-ID '23-20007@fe80::215:ff:fee3:e25c%w...At this point the process does not respond to
SIGUSR1or any furtherqs passed to stdin. Passing the-timeout 1sarg seems to make no difference.NOTE: if I pass
-recv_timeout 100(or any shorter ms value) the process does in fact terminate when signaled as expected but only after a timeout event has taken place. However, if I pass a longer value, say 10 secs-recv_timeout 10000, then the same problem can be triggered if type the 3qsprior to the timeout of the first call attempt.I attached with the debugger and found that the problem seems to do with the stat check here: https://github.com/SIPp/sipp/blob/master/src/sipp.cpp#L736
It looks like the call to
main_scenario->stats->GetStat(CStat::CPT_C_CurrentCall)returns the number of active calls counter (also what the curses ui reports)? The loop doesn't terminate when the bug is triggered because this counter seems to never be decremented/reset. Oddly, after a call timeout it does seem to have been decremented elsewhere and eventually decreases to0after a couple more loops intraffic_thread().