> On Jun 8, 2023, at 11:22 PM, Meng Ruijie 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
> On Jun 8, 2023, at 5:03 PM, Meng Ruijie 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,
Hi,
We found one memory leak in the function handleCmd_PLAY in live.2023.05.10.
Here is the bug report from the valgrind:
---
==1755== Invalid read of size 1
==1755==at 0x483EF46: strlen (in
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1755==by 0x4E2FD14: __v
Jie,
Thanks for the report. I have just installed a new version (2023-05-10) of the
code that fixes this.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/m
hi all,
I found a memory leak in version 2023.0303. The following is my patch,
please take a look.
Best Regards,
Jie
diff --git a/liveMedia/RTSPServer.cpp b/liveMedia/RTSPServer.cpp
index d649779..1210702 100644
--- a/liveMedia/RTSPServer.cpp
+++ b/liveMedia/RTSPServer.cpp
@@ -493,6
Streaming Media - development & use
Subject: Re: [Live-devel] Memory leak in OnDemandServerMediaSubsession
- External Email -
> On Jan 10, 2022, at 9:18 PM, Ba Jinsheng wrote:
>
> Unfortunately, in my experimental environment, it looks unlikely that the
> objects are delete
> On Jan 10, 2022, at 9:18 PM, Ba Jinsheng wrote:
>
> Unfortunately, in my experimental environment, it looks unlikely that the
> objects are deleted, even after 60 seconds.
If you are running the unmodified LIVE555 server code, then the function
GenericMediaServer::ClientSession::liv
: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Memory leak in OnDemandServerMediaSubsession
- External Email -
> On Jan 10, 2022, at 7:54 PM, Ba Jinsheng
> mailto:bajinsh...@u.nus.edu>> wrote:
>
> I am not sure if the design is
> On Jan 10, 2022, at 7:54 PM, Ba Jinsheng wrote:
>
> I am not sure if the design is like this, but it does incur unstopping memory
> increasing.
>
>
> OnDemandServerMediaSubsession::getStreamParameters() in
> liveMedia/OnDemandServerMediaSubsession.cpp
> This function will allocate a new S
ive-devel On Behalf Of Ross Finlayson
Sent: Monday, January 10, 2022 2:06 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Memory leak in OnDemandServerMediaSubsession
- External Email -
Unfortunately, reports of memory leaks aren’t worthwhile fo
Unfortunately, reports of memory leaks aren’t worthwhile for me to investigate
unless you can identify a specific object (class) that is allocated, and not
later deallocated. Otherwise I can’t be sure that the heap isn’t just growing
due to fragmentation - i.e., not a real memory leak.
Ross F
To whom it may concern,
I would like to report a memory leak issue in Live555.
When sending multiple times of the content in 'command.rtsp' to the live555,
the memory usage of live555 significantly increase, and never reduce.
(In reality, need to update the session ID dynamically)
The initial me
Dear Ross Finlayson,
I want to report an memory leak bug in the MPEGProgramStreamParser.
Sorry, I don't provide poc this time because I can not reproduce it in single
request.
But in a long time running, the memory would always exceed 3GB and the memory
leak is detected by Address Sanitizer an
> On Aug 13, 2021, at 6:05 PM, Ba Jinsheng wrote:
>
> But would delete[] be better?
Yes (although in this case it doesn’t really matter, because the ‘objects’
being allocated in an array are just ‘char’s).
But I’ve released a new version (2021.08.14) that fixes this.
Ross Finlayson
Live Ne
-
From: live-devel On Behalf Of Ross Finlayson
Sent: Saturday, August 14, 2021 12:48 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Memory Leak in AC3AudioStreamFramer
- External Email -
Thanks again for the report. This bug has also been fixed in
Thanks again for the report. This bug has also been fixed in the latest
“LIVE555 Streaming Media” release (2021.08.13).
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.
Dear Ross Finlayson,
Sorry for many emails and thanks for your reply.
I want to report another memory leak bug in the AC3AudioStreamFramer.
In liveMedia/AC3AudioStreamFramer.cpp:306, fSavedFrame pointer is assigned to a
new allocated heap memory. There are two delete[] operations to free this
Once again, you’re going to have to figure this out yourself.
In particular, you should check:
- What happens if you use the unmodified “LIVE555 Proxy Server” code?
- What happens if your application contains only the code that you’ve
shown below (without *any* “LIVE555 Proxy Serv
Hi,
I am using scheduleDelayedTask to execute a function dummytask repeatedly.
Code:
void dummytask()
{
.
.
.
env->taskScheduler().scheduleDelayedTask(uSecsToDelay,
(TaskFunc*)dummyTask, NULL);
}
int main()
{
.
.
.
dummytask();
env->taskScheduler().doEve
There’s no memory leak here, because “setSDPLinesFromRTPSink()” is called (from
"OnDemandServerMediaSubsession::sdpLines()”) only when “fSDPLines” is NULL.
(Note line 60 of “OnDemandServerMediaSubsession.cpp”.)
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
__
1. Case Description.
Leaks occur when requesting the same rtsp token at the same time.
(The same rtsp token means the same url.)
2. Modification code.
original code.
void OnDemandServerMediaSubsession
::setSDPLinesFromRTPSink(RTPSink* rtpSink, FramedSource* inputSource,
unsigned estBitrate) {
..
Thanks for the report. This is now fixed in the latest version (2015.07.31) of
the “LIVE555 Streaming Media” code, released just now.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
h
Hi,
Found a memory leak in class ProxyServerMediaSession. This leak grows with
more number of cameras registered to live555ProxyServer.
class PresentationTimeSessionNormalizer is derived class of Medium. So that
whenever object of class PresentationTimeSessionNormalizer is created, it
creates its
Jianliang,
Thanks for the report. Yes, you're correct - this is a memory leak (because
response handlers should be deleting the 'response string'). THis will be
fixed in the next release of the software.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
Memory leak detected at RTSPClient::responseHandlerForHTTP_GET1(int
responseCode, char* responseString) for the latest release version
(2013-07-03). The repsonseString isn't deleted.
___
live-devel mailing list
live-devel@lists.live555.com
http://list
> I'm developing a RTSP client application. While testing I've found a possible
> memory leak in RTSPClient::handleRequestError(). While calling the handler
> there is a string duplication of the error string.
No, there's no memory leak here. In *all* calls to a RTSP "responseHandler"
(includi
Hello,
I'm developing a RTSP client application. While testing I've found a possible
memory leak in RTSPClient::handleRequestError(). While calling the handler
there is a string duplication of the error string.
IMHO this string should be freed inside RTSPClient::handleRequestError() after
the
> When the RTSPClient execute SETUP request, the sessionId is stored in the
> MediaSubSession.
And it gets delete[]d later, when the RTSPClient does a "TEARDOWN". So this
isn't really a memory leak.
However, I can see why "valgrind" might get confused by this. The "sessionId"
field in "Media
Hi Ross,
When the RTSPClient execute SETUP request, the sessionId is stored in the
MediaSubSession.
36 bytes in 4 blocks are definitely lost in loss record 469 of 573
(see: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks)
at 0x4C27939: operator new[](unsign
It seems to be memory leak in BasicTaskScheduler0::scheduleDelayedTask.
No there's not.
AlarmHandler* alarmHandler = new AlarmHandler(proc, clientData,
timeToDelay); // here! where is 'delete'
It gets deleted later, when the handler gets called. (Note the
"delete this" in the implement
Thanks for your good job.
It seems to be memory leak in BasicTaskScheduler0::scheduleDelayedTask.
just i guess, check it out.
AlarmHandler* alarmHandler = new AlarmHandler(proc, clientData, timeToDelay);
// here! where is 'delete'
fDelayQueue.addEntry(alarmHandler);
and another question.
what about MediaSubSession::sessionId.
it was created was strDup.
and where to delete it.
This field is not managed by "MediSubsession" itself. Instead, it is
assigned by "RTSPClient" while performing the RTSP "SETUP" command,
and is deleted automatically later (again, b
:06 PM
To: "LIVE555 Streaming Media - development & use";
Subject: Re: [Live-devel] memory leak
>m_pUsageEnvironment = BasicUsageEnvironment::createNew(*m_pTaskScheduler);
>if(m_pUsageEnvironment == NULL)
>{
>service_error.init(service_error_type_failed,"BasicUsageE
m_pUsageEnvironment = BasicUsageEnvironment::createNew(*m_pTaskScheduler);
if(m_pUsageEnvironment == NULL)
{
service_error.init(service_error_type_failed,"BasicUsageEnvironment::createNew
failed");
return service_error;
}
and . how to delete this m_pUsageEnvironment;
Objects of class "UsageEnv
nvironment;
-- Original --
From: "Ross Finlayson";
Date: Tue, Nov 2, 2010 05:10 PM
To: "LIVE555 Streaming Media - development & use";
Subject: Re: [Live-devel] memory leak
>i don't know how to delete your variant.
>and i saw ma
i don't know how to delete your variant.
and i saw many strDup string.wouldn't delete at all.
why are you doing this.
or am i wrong usage?
I'm sorry, but I don't really understand your question.
Can you give a specific example of something that you think is a memory leak?
--
Ross Finlayson
Liv
hi,dear friend.
i don't know how to delete your variant.
and i saw many strDup string.wouldn't delete at all.
why are you doing this.
or am i wrong usage?___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/list
Our simple solution for this is to prevent recreating the socket
hash table in lookupSocketDescriptor when createIfNotFound is set to
false and exiting with NULL before socketHashTable is called.
OK, I think I have fixed this now in the latest release of the code
(2010.06.11).
--
Ross Finlay
Live-devel] memory leak using tcp
Hi,
i built a RTSP-client with the latest source codes based on the openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using UDP, everything works fine and without memory leaks, but using TCP, there are four small memory leaks as reported earlier by Kami
ail/live-devel/2005-September/003174.html issue I could
not find any answer or solution neither.
Best regards
Alex
__
Od: "Ross Finlayson"
Komu: LIVE555 Streaming Media - development & use
Datum: 11.06.2010 04:31
Předmět:
i built a RTSP-client with the latest source codes based on the
openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using
UDP, everything works fine and without memory leaks, but using TCP,
there are four small memory leaks as reported earlier by Kamil in
the following thread:
http://l
Hi,
i built a RTSP-client with the latest source codes based on the
openRTSP-example to receive H.264, MPEG4 and MJPEG-Streams. Using UDP,
everything works fine and without memory leaks, but using TCP, there are four
small memory leaks as reported earlier by Kamil in the following thread:
http
I created simple video stream (mpeg4) and I'm using FileSink as default sink.
Everything is fine until I try to end all sessions and streaming.
Everything ends
and every subsession and session is closed but there still apears to
be memory leak
somwhere.
I'm opening the stream like this:
1. Get
Hi.
I created simple video stream (mpeg4) and I'm using FileSink as default sink.
Everything is fine until I try to end all sessions and streaming. Everything
ends
and every subsession and session is closed but there still apears to be memory
leak
somwhere.
I'm opening the stream like this:
1.
In teardownMediaSubsession in RTSPClient, the subsession's sessionId
variable is deleted and reset. However *only if* the teardown
succeeds. If the teardown fails and the MediaSubsession is
subsequently closed using the proper method, then the sessionId will
not be freed. I suggest also del
Hi Ross,
In teardownMediaSubsession in RTSPClient, the subsession¹s sessionId
variable is deleted and reset. However *only if* the teardown succeeds.
If the teardown fails and the MediaSubsession is subsequently closed using
the proper method, then the sessionId will not be freed. I suggest als
exiting from
that loop,,,it will be great...
Thanks,
Soumya
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ross Finlayson
Sent: Wednesday, October 08, 2008 7:47 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Memory Leak w
In the downloaded code the doEventLoop() was not exiting and it was a
infinite loop. Now i changed the code
so that it will exit on keyboard hit. Then also it is not exiting properly.
What do you mean "not exiting properly"? Is "doEventLoop()" (when
you add a 'watch variable' returning, or n
Hi,
In the downloaded code the doEventLoop() was not exiting and it was a
infinite loop. Now i changed the code
so that it will exit on keyboard hit. Then also it is not exiting properly.I
think it is
because of some memory leaks. Can anyone give an idea about the resources to
be freed while exitin
>1) why we have make sure the fRTPSink, fRTCPInstance, fRTPgs,
>fRTCPgs is not NULL. After the SETUP, all of them must have been
>allocated.
No, not necessarily. If we are streaming via raw UDP (instead of via
RTP/UDP), then "fRTPSink" and "fRTCPInstance" will be NULL (with
"fUDPSink" being n
I was puzzled when I'v read the following code:
OnDemandServerMediaSubsession.cpp:447 StreamState::startPlaying()
if (dests- >isTCP) {
// Change RTP and RTCP to use the TCP socket instead of UDP:
if (fRTPSink != NULL) {
fRTPSink- >addStreamSocket(dests- >tcpSocketNum, dests-
>
51 matches
Mail list logo
