PChar memory leak

6 visninger
Gå til det første ulæste indlæg

Tom McCobb

ulæst,
7. sep. 2001 16.56.4207.09.2001
til
The following code results in a memory leak, according to TurboPower's
Memory Sleuth Codewatch:

Procedure foo;
var
Result400 : PChar;
Begin
{Result400:= nil;}
Result400 :=
DDEConversation.RequestData('Table.Open(SY_Company_MSTR)');
{StrDispose(Result400);}
{Result400:= nil;}
end;

I have tried it with and without the code in brackets. FYI, the
RequestData method returns a PChar, and it is used to test for success
or failure of the method.

Not sure how to get rid of the memory leaks.

Tom

David Saracini

ulæst,
7. sep. 2001 17.22.0107.09.2001
til

"Tom McCobb" <tmcc...@yahoo.com> wrote in message
news:3B99348A...@yahoo.com...

Tom,

How does RequestData allocate the memory for the PChar?

David Saracini

Ray Lischner

ulæst,
7. sep. 2001 17.21.3007.09.2001
til
Tom McCobb wrote:

> Result400 :=
> DDEConversation.RequestData('Table.Open(SY_Company_MSTR)');

See TDdeClientConv.RequestData in the online help.
--
Ray Lischner, author of Delphi in a Nutshell
http://www.tempest-sw.com

Tom McCobb

ulæst,
7. sep. 2001 17.54.4907.09.2001
til
From the on-line help:

RequestData automatically allocates memory to store the returned data, but
applications must dispose of this PChar string after processing it. This is
done with the StrDispose function.

That indicates to me that the follwoing should work:

Procedure foo;
var
Result400 : PChar;
Begin
Result400 :=

DDEConversation.RequestData('Table.Open(SY_Company_MSTR)');
StrDispose(Result400);
end;

CodeWatch still indicates a memory leak. Maybe it's the ddeConvItem
compoment that is doing it?

Tom

Ray Lischner

ulæst,
7. sep. 2001 18.39.5107.09.2001
til
Tom McCobb wrote:

> Procedure foo;
> var
> Result400 : PChar;
> Begin
> Result400 :=
> DDEConversation.RequestData('Table.Open(SY_Company_MSTR)');
> StrDispose(Result400);
> end;
>
> CodeWatch still indicates a memory leak. Maybe it's the ddeConvItem
> compoment that is doing it?

A casual reading of the source code doesn't turn up any obvious leaks.
It looks to me like everything is being freed correctly.

What, exactly, does CodeWatch say? Can you reduce the program to the
smallest possible, compilable example that manifests the leak?

Tom McCobb

ulæst,
8. sep. 2001 17.46.5608.09.2001
til
I did isolate the code in a small program and anytime the
DDEConv.RequestData returned a value other than nil, the leak was
reported.

A try...finally block gets rid of the leak:

...
var
Result400: Pchar;
begin
try


Result400 :=
DDEConversation.RequestData('Table.Open(SY_Company_MSTR)');

finally
StrDispose(Result400);
end;
end;

I am happy with the result - not sure why it works though, when the
original code doesn't.

Tom McCobb

Barry Kelly

ulæst,
8. sep. 2001 21.29.4808.09.2001
til
In article <3B9A91D0...@yahoo.com>
Tom McCobb <tmcc...@yahoo.com> wrote:

> I am happy with the result - not sure why it works though, when the
> original code doesn't.

Maybe Abort got called someplace.

-- Barry

Svar alle
Svar forfatteren
Videresend
0 nye indlæg