[Live-devel] Memory leak in handleCmd_PLAY

[Meng Ruijie]

Sorry, but we don't modify the code to call exit()​.

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)
==2720==    by 0x1315DB: RTSPServer::RTSPClientSession::handleCmd_SETUP_afterLookup2(ServerMediaSession*) (RTSPServer.cpp:1585)
==2720==    by 0x12F8C3: RTSPServer::RTSPClientConnection::handleRequestBytes(int) (RTSPServer.cpp:887)
==2720==    by 0x170C70: GenericMediaServer::ClientConnection::incomingRequestHandler() (GenericMediaServer.cpp:324)
==2720==    by 0x188D19: BasicTaskScheduler::SingleStep(unsigned int) (BasicTaskScheduler.cpp:153)
==2720==    by 0x18A3C2: BasicTaskScheduler0::doEventLoop(char volatile*) (BasicTaskScheduler0.cpp:82)
==2720==    by 0x15EFD4: AC3AudioStreamFramer::samplingRate() (AC3AudioStreamFramer.cpp:112)
==2720==    by 0x143A87: AC3AudioFileServerMediaSubsession::createNewRTPSink(Groupsock*, unsigned char, FramedSource*) (AC3AudioFileServerMediaSubsession.cpp:58)
==2720==    by 0x17159E: 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:177)
==2720==    by 0x1315DB: RTSPServer::RTSPClientSession::handleCmd_SETUP_afterLookup2(ServerMediaSession*) (RTSPServer.cpp:1585)
==2720==    by 0x12F8C3: RTSPServer::RTSPClientConnection::handleRequestBytes(int) (RTSPServer.cpp:887)
==2720==
==2720== 160 bytes in 1 blocks are definitely lost in loss record 326 of 353
==2720==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2720==    by 0x17177C: 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:210)
==2720==    by 0x1315DB: RTSPServer::RTSPClientSession::handleCmd_SETUP_afterLookup2(ServerMediaSession*) (RTSPServer.cpp:1585)
==2720==    by 0x12F8C3: RTSPServer::RTSPClientConnection::handleRequestBytes(int) (RTSPServer.cpp:887)
==2720==    by 0x170C70: GenericMediaServer::ClientConnection::incomingRequestHandler() (GenericMediaServer.cpp:324)
==2720==    by 0x188D19: BasicTaskScheduler::SingleStep(unsigned int) (BasicTaskScheduler.cpp:153)
==2720==    by 0x18A3C2: BasicTaskScheduler0::doEventLoop(char volatile*) (BasicTaskScheduler0.cpp:82)
==2720==    by 0x15EFD4: AC3AudioStreamFramer::samplingRate() (AC3AudioStreamFramer.cpp:112)
==2720==    by 0x143A87: AC3AudioFileServerMediaSubsession::createNewRTPSink(Groupsock*, unsigned char, FramedSource*) (AC3AudioFileServerMediaSubsession.cpp:58)
==2720==    by 0x17159E: 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:177)
==2720==    by 0x1315DB: RTSPServer::RTSPClientSession::handleCmd_SETUP_afterLookup2(ServerMediaSession*) (RTSPServer.cpp:1585)
==2720==    by 0x12F8C3: RTSPServer::RTSPClientConnection::handleRequestBytes(int) (RTSPServer.cpp:887)
==2720==
==2720== LEAK SUMMARY:
==2720==    definitely lost: 256 bytes in 2 blocks
==2720==    indirectly lost: 0 bytes in 0 blocks
==2720==      possibly lost: 0 bytes in 0 blocks
==2720==    still reachable: 25,440 bytes in 372 blocks
==2720==         suppressed: 0 bytes in 0 blocks
==2720== Reachable blocks (those to which a pointer was found) are not shown.
==2720== To see them, rerun with: --leak-check=full --show-leak-kinds=all


------
Kind Regards,
Ruijie
________________________________
From: live-devel <live-devel-bounces at us.live555.com> on behalf of Ross Finlayson <finlayson at live555.com>
Sent: Thursday, June 8, 2023 16:28
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Subject: Re: [Live-devel] Memory leak in handleCmd_PLAY

        - External Email -



> On Jun 8, 2023, at 5:03 PM, Meng Ruijie <ruijie_meng at u.nus.edu> wrote:
>
> Hi,
>
> We found one memory leak

No you didn’t.  You ran “valgrind” on an application that uses our RTSP server implementation.  At one point in the program, you exited it (presumably by modifying the code).  When you exited the program, “valgrind” reported  that 160 bytes were “definitely lost”.  So what?  How do know that these 160 bytes would not have been freed later, had you not decided to modify the code to call “exit()”?  And you didn’t say what those 160 bytes were, and where they were allocated.

Please don’t bother posting random output from “valgrind”, unless you also specifically identify a problem in the code.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/


_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20230608/2eba2fda/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memoryLeak.tar.gz
Type: application/gzip
Size: 2590410 bytes
Desc: memoryLeak.tar.gz
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20230608/2eba2fda/attachment-0001.bin>