Closed gitkoyot closed 6 months ago
I tried to extract issue to following scenarios. When call rate is set to 10CPS - everything works on my machine. When I switch to 100CPS it crashes
g711PCMUstream.zip uac.sh.txt uac.xml.txt uas.sh.txt uas.xml.txt valgrind-uas.txt.txt
please dont mind uac crashing - it crashes because connection is reset by peer
Hi! Observe the same behaviour
`
`
This crushes sipp with segmentation fault when increase CPS over 35-40, concurrent calls ~ 1500.
Caused by use-after-free, introduced by d8899fca5beeb00dba0d7e40a622ddce0fb88f64 under https://github.com/SIPp/sipp/pull/521
I'll look into a fix
Suspect a duplicate of #610, #576
@orgads I'm considering whether the best solution here might be to revert #521
The high-level problem with the PR is that it changes the pcap play and RTP stream actions to hold per-call variables, but without changing the underlying control blocks to represent that. Instead, the action that is still in use for previous calls are partially freed before being altered and reused for a new call. The issues I've identified coming from this are:
How crucial is #521 to you? I count at least 6 users from the issues (me included) who have hit this, and it seems to me that the best way to resolve this for now would be to remove the PR, either pending a suitable reworking to resolve the issues above, or indefinitely if the feature isn't important enough.
I need it. We use it all the time.
Is it too hard to fix?
Point 3 above isn't fixable - it turns the PCAP handling from O(1) to O(N), where N=concurrent calls. It intrinsically changes the scalability of running SIPp with media.
The other three points (1,2,4) would be resolvable, but it's at the scale of the fix being bigger than the initial code changes.
I'm surprised you don't have issues; what sort of scenarios are you running? Do you run concurrent media streams using PCAP play?
Is it only for pcap? we use wav streaming.
You may revert the change. I'll try to look into it if I find the time for it.
Looks like WAV files use RTPStream rather than PCAP play? When I looked at the effect of the code changes, it looks like RTPStream doesn't suffer the same issues as the PCAP play: Some logic in rtpstream.cpp suggests each individual file is cached (rather than one per call even if they're the same), that the same use-after-free issues are avoided.
I could remove the feature for PCAP play without removing for RTPStream?
Sure, thank you.
Hello, I have a scenario where both UAC and UAS are playing 10 sec audio. I noticed that sometimes UAS part crashes. When I executed it with valgrind this is what I found:
also stack trace points to similar
i suspect (and I might be wrong) that the issue is that the call is shorter than the audio file. Or there is another race condition or my scripts (attached in separate message) are wrong.