> Sorry for the trouble.
>
> I just fixed an error in another part of the program, a call to a driver,
> having nothing to do with the TWSocket or really anything related to it,
> and
> AQTime reports only one leak of 4096 bytes. This one I have no idea what
> it
> is. It appears to be from MakeO
, January 07, 2008 11:10 AM
To: 'ICS support mailing'
Subject: RE: [twsocket] Memory leaks...
Hi,
The TWSocket is on a TDataModule. I am creating the TDataModule and yes I am
freeing it. If I was not freeing the TDataModule it would be reported as a
leak, along with the other items on the TData
AQTime?
Thanks for the response,
Mark
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of DZ-Jay
Sent: Monday, January 07, 2008 10:53 AM
To: ICS support mailing
Subject: Re: [twsocket] Memory leaks...
On Jan 7, 2008, at 11:45, zayin wrote:
> I loca
On Jan 7, 2008, at 11:45, zayin wrote:
> I located the archive and I see his response.
>
> The leak is reported at program termination not during normal
> execution.
Are you creating the class object yourself, and if so, are you sure it
is being destroyed? Can you offer some code?
dZ
Hello Mark,
When you call connect the function returns immediatily, but the
connection happens in background. So it is normal there is memory
allocated. Needed memory is not nececarely a leak.
---
Rgds, Wilfried [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
http://www.mestdagh.biz
S
> > If the stream behaviour is what you need, I don't see any
> > problem with that.
>
> What about memory allocation ?
It is better to keep the object created of course. But this doesn't change
anything regarding to what the object optimize the memory it may have
allocated.
Contribute to the SSL
> If the stream behaviour is what you need, I don't see any problem with
> that.
What about memory allocation ?
Paul
PS: for all who's concerned about memory leaks :
I've asked Pierre le Riche (author of FastMM) about memory consumption.
The only thing you need to check is the virtual memory.
>> It is always interesting to reuse objects instead of destroying them and
>> recreate a fresh copy. But speaking about stream, it depends on the type
>> of
>> stream. A TFileStream has to be destroyed to close the file.
>
>
> So as long I'm sending streams with a HttpCli, I don't need to free the
On 10/9/06, Francois PIETTE <[EMAIL PROTECTED]> wrote:
> > I thought about extending HTTPCli and adding a property,
> > "CreateMemoryStreams". I use memory streams with HTTPCli and have to
> > do this for every use. It would be nice it the create/free code was
> > already done for me with a simple
>> > It is always interesting to reuse objects instead of destroying them
>> > and
>> > recreate a fresh copy. But speaking about stream, it depends on the
>> > type
>> > of
>> > stream. A TFileStream has to be destroyed to close the file.
>
> I thought about extending HTTPCli and adding a proper
On 10/9/06, Paul <[EMAIL PROTECTED]> wrote:
> > It is always interesting to reuse objects instead of destroying them and
> > recreate a fresh copy. But speaking about stream, it depends on the type
> > of
> > stream. A TFileStream has to be destroyed to close the file.
I thought about extending HT
> It is always interesting to reuse objects instead of destroying them and
> recreate a fresh copy. But speaking about stream, it depends on the type
> of
> stream. A TFileStream has to be destroyed to close the file.
So as long I'm sending streams with a HttpCli, I don't need to free the
strea
> > That's a good news. It eliminate the need to investigate for the SSL
part.
> > Have a look at your global dynamic variables and dynamic variables
> > assigned
> > to forms which have the same timelife as the program.
>
> Everything is created in runtime.
> Basically, I created an object that I
> That's a good news. It eliminate the need to investigate for the SSL part.
> Have a look at your global dynamic variables and dynamic variables
> assigned
> to forms which have the same timelife as the program.
Everything is created in runtime.
Basically, I created an object that I can use in a
> I see no difference between http and https. so SSL has nothing to do with
it
That's a good news. It eliminate the need to investigate for the SSL part.
Have a look at your global dynamic variables and dynamic variables assigned
to forms which have the same timelife as the program.
Contribute to
I see no difference between http and https. so SSL has nothing to do with it
Paul
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Sunday, October 08, 2006 8:40 PM
Subject: Re: [twsocket] Memory leaks
> Paul
> > If FastMM doesn't report any leak, then the increase probably result
> > from memory fragmentation.
>
> I think FastMM solved the memory-fragmention-problem of the old Delphi
> memory manager. That's at least my expierence in applications where
> GetMem/FreeMem is called frequently (several tho
Paul wrote:
> Hi Arno,
>
> i don't see any reason why i can't have a clent in the main thread
> and one in a seperate thread working together with the dll's.
>
> This would mean that 2 applications wouldn't be able to use the same
> SSL-dll's also
OpenSsl is thread safe as long as we provide the
l
>
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Sunday, October 08, 2006 8:49 PM
> Subject: Re: [twsocket] Memory leaks
>
>
>> Paul wrote:
>>>> B
Hi Arno,
i don't see any reason why i can't have a clent in the main thread and one
in a seperate thread working together with the dll's.
This would mean that 2 applications wouldn't be able to use the same
SSL-dll's also
Paul
--
To unsubscribe or change your settings for TWSocket mailing
I'm using V5 with this application.
I don't have this unit
Paul
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Sunday, October 08, 2006 8:49 PM
Subject: Re: [twsocket] Memory leaks
> Paul wro
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Sunday, October 08, 2006 8:49 PM
Subject: Re: [twsocket] Memory leaks
> Paul wrote:
>>> BTW: Are you using (OverbyteIcs)SslThrdLock.pas which is a Must w
Paul wrote:
>> BTW: Are you using (OverbyteIcs)SslThrdLock.pas which is a Must when
>> running OpenSSL multi-threaded?
>
>
> No, how to use it ?
It's described in the unit header.
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
>
>
> Paul
--
To unsubscribe or ch
> BTW: Are you using (OverbyteIcs)SslThrdLock.pas which is a Must when
> running OpenSSL multi-threaded?
No, how to use it ?
Paul
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.over
Paul wrote:
> Hi,
>
> When my program is running (sending a stream about each second with
> SslHttpCli), I see the memory useage in the taskmanager increasing
> continuous.
May be cached SSL sessions are the reason?
---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
Francois PIETTE wrote:
> If FastMM doesn't report any leak, then the increase probably result
> from memory fragmentation.
I think FastMM solved the memory-fragmention-problem of the old Delphi
memory manager. That's at least my expierence in applications where
GetMem/FreeMem is called frequently
Paul wrote:
> Hi,
>
> When my program is running (sending a stream about each second with
> SslHttpCli), I see the memory useage in the taskmanager increasing
> continuous.
> The SslHttpCli is running in a seperate thread.
> FastMM doesn't report any memory leaks, except for a string(20 bytes)
> A
If FastMM doesn't report any leak, then the increase probably result from
memory fragmentation.
It is also possible that memory allocation are done in global objects (I
don't know which one) which a freeed at program exist and nevertheless "eat"
more and more memory.
--
Contribute to the SSL Ef
28 matches
Mail list logo
