delphi字符串泄漏 [英] delphi string leak

查看:562
本文介绍了delphi字符串泄漏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用Delphi XE,并编写一个使用RemObjects SDK进行通信的应用程序(如果可能是相关的)。我有FastMM调试,有时(不总是)当我关闭它给一个单一的意外的内存泄漏警告。 发生意外的内存泄漏。意外的小块泄漏是:117-124字节:UnicodeString x 1。非常偶尔,我得到x2报告。



现在,我的理解是,字符串是引用计数,并且由于没有其他对象涉及到导致泄漏,可能是什么可能导致这种情况的情况?在此StackOverflow问题中,人们找不到泄漏的方法。



如果没有明显的方法,那么我将下载最新的FastMM源代码(似乎不包括在XE源代码中)。



[解决一次]解决方案是安装FastMM源,并启用FullDebugMode获取堆栈跟踪。

解决方案

想到哪里可以泄漏字符串而不刻意破坏字符串的唯一方法(如手动递增引用计数或做一些凌乱的指针操作)是使用threadvar。



像帮助文件一样,


编译器管理的通常为
的动态变量(长字符串,
宽字符串,动态数组,
变体和接口)可以使用threadvar声明为
,但
编译器不会自动释放
每个执行线程由
创建的堆分配内存。如果你使用
这些数据类型在线程变量
,你有责任在线程终止之前从
线程中处理
的内存。


除此之外,没有什么值得注意的还没有被陈述。



这确实是问题,具体代码如下:

  threadvar 
g_szAuthentication:String ;


程序TMyBase.SetAuthentication(szUserName,szPassword:String);
begin
g_szAuthentication:='?name ='+ szUserName +'& pass ='+ szPassword;
结束


I'm working with Delphi XE, and writing an application that is using RemObjects SDK to communicate (in case that may be relevant). I have FastMM debug on, and sometimes (not always) when I close it gives a warning about a single "Unexpected Memory Leak". "An unexpected memory leak has occurred. The unexpected small block leaks are: 117-124 bytes: UnicodeString x 1". Very occasionally, I get x2 reported.

Now, my understanding is that Strings are reference counted, and since there is no other object involved to cause the leak, what might be the situation that could cause this to happen? In this StackOverflow question people cannot find a way to make a leak.

If there is no obvious way, then I will download the latest FastMM source (it appears not to be included with the XE source).

[Edit once resolved] The solution to finding this was to install FastMM source, and enable the FullDebugMode to get the stack trace.

解决方案

The only way that comes to mind where you can leak a string without deliberately breaking it (like manually incrementing the ref count or doing some messy pointer operation) is by using threadvar.

Like the help file states,

Dynamic variables that are ordinarily managed by the compiler (long strings, wide strings, dynamic arrays, variants, and interfaces) can be declared with threadvar, but the compiler does not automatically free the heap-allocated memory created by each thread of execution. If you use these data types in thread variables, it is your responsibility to dispose of their memory from within the thread, before the thread terminates.

Beside that, there's nothing that comes to mind that wasn't already stated.

[Edit by questioner] This was indeed the issue, and the specific code was as follows:

threadvar
    g_szAuthentication : String;


procedure TMyBase.SetAuthentication(szUserName, szPassword: String);
begin
    g_szAuthentication := '?name=' + szUserName + '&pass=' + szPassword;
end;

这篇关于delphi字符串泄漏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆