retamia
commented
3 months ago I did some preliminary code inspection. The two playback endpoints share the same SrsLiveStream instance. After the first one disconnects, alive_ is set to false.
alive_ = true;
err = do_serve_http(w, r);
alive_ = false;In the SrsHttpStreamServer::http_unmount(SrsRequest* r) function, stream->alive() is already false, so mux.unhandle will free the SrsLiveStream. This causes the other connection coroutine to return to its execution environment after the SrsLiveStream instance has already been freed.
// Wait for cache and stream to stop.
int i = 0;
for (; i < 1024; i++) {
if (!cache->alive() && !stream->alive()) {
break;
}
srs_usleep(100 * SRS_UTIME_MILLISECONDS);
}
// Unmount the HTTP handler, which will free the entry. Note that we must free it after cache and
// stream stopped for it uses it.
mux.unhandle(entry->mount, stream.get());
winlinvip
!!! Before submitting a new bug report, please ensure you have searched for any existing bugs and utilized the
Ask AIfeature at https://ossrs.io or https://ossrs.net (for users in China). Duplicate issues or questions that are overly simple or already addressed in the documentation will be removed without any response.Describe the bug
When there are two playback endpoints, a heap-use-after-free crash occurs after the streaming endpoint disconnects.
Version release6.0
To Reproduce Steps to reproduce the behavior:
OBSstart streamingffmpeg -rw_timeout 10000000 -i http://127.0.0.1:8080/live/test.flv -c copy -f flv -y /dev/nullffmpeg -rw_timeout 10000000 -i http://127.0.0.1:8080/live/test.flv -c copy -f flv -y /dev/nullOBSstop streamingExpected behavior When the streaming and playback endpoints end normally, SRS will not crash
Screenshots
Additional context