> 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,
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
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
> 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.
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/
__
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
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/
_
> 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
> 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
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
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
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
Dear Ross & all,
first of all, sorry for the broken link in my last response to this topic, the
correct link follows below. My e-mail client has been playing around with the
links.
http://lists.live555.com/pipermail/live-devel/2005-September/003174.html
Now. I can confirm, that this old prob
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
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
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
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
>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
32 matches
Mail list logo
