> On Jun 8, 2023, at 11:22 PM, Meng Ruijie <ruijie_m...@u.nus.edu> wrote:
>
> We now show you where the memory leak happens as follows. We also attached
> the reproduction steps, so that you can reproduce this bug based on the
> README.
>
> ----
>
> ==2720== 96 bytes in 1 blocks are definitely lost in loss record 292 of 353
> ==2720== at 0x483BE63: operator new(unsigned long) (in
> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==2720== by 0x1716BF:
> OnDemandServerMediaSubsession::getStreamParameters(unsigned int,
> sockaddr_storage const&, Port const&, Port const&, int, unsigned char,
> unsigned char, TLSState*, sockaddr_storage&, unsigned char&, unsigned char&,
> Port&, Port&, void*&) (OnDemandServerMediaSubsession.cpp:204)
No, this is NOT a memory leak. This memory (the “StreamState” object) is
allocated for each stream, and is reclaimed when either:
1/ The RTSP client closes the stream (by sending a RTSP “TEARDOWN”
command, or
2/ The server automatically closes the stream and reclaims the stream’s
state after “reclamationSeconds” of inactivity (by default, 65 seconds).
“valgrind” is wrong here.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
