Closed rubu closed 4 years ago
@rubu Thank you very much! Since we are currently doing a major modification, the PR you sent will be applied later to avoid merge-conflict as much as possible.
Thank you again for your contribution.
Ok, I'd really like to get in touch to understand more what is going on in the dev branch and what changes will happen, since we have done a lot of features on the master that we could contribute (like stream bypass, reworked the fragmentation header to allow more than 3 fragments in a packet etc).
@rubu There is a lot of work on the OME development team, including MPEG-TS input, LL-DASH stabilization, and Origin-Edge structure rewriting. Also, our next goal is to merge all of these into the master quickly. Therefore, if you send PR before that, we will merge together later.
Thank you very much for your attention!
This issue has been closed since it has been inactive for quite some time. If you want to continue discussing this issue, please feel free to reopen it.
I have a setup where i publish rtmp feed with ffmpeg and occasionally I encountered segmentation faults when killing ffmpeg.
I traced down the issue to the following - when a stream is closed the RtcApplication::DeleteStream iterates through the session map from the stream:
But calling
RtcSignallingServer::Disconnect
can boil down to callingWebRtcPublisher::OnStopCommand
which will callStream::RemoveSession(int)
(see stack trace below), thus the stream map in the stream is touched while the for loop is still in progress thus invalidating the underlying iterators in the loop.Consider this stack trace:
On the top of the stack we are in
tream::RemoveSession(session_id_t id)
, which erases the stream, whileRtcApplication::DeleteStream()
is still in the loopfor(auto it = sessions.begin(); it != sessions.end();)
.I'll try to provide a PR for this:)