【问题标题】:To Identify which native method caused memory leak识别哪个本机方法导致内存泄漏
【发布时间】:2012-08-01 23:30:00
【问题描述】:

我正在调试 ASP.NET Web 应用程序中的 OOM 问题。使用性能计数器,发现非托管空间存在问题。因此,我使用 Debugdiag 生成转储并从中创建内存压力分析报告。


总结:

oracommon10.dll 负责 270.16 MB 的未完成分配。

Top 内存消耗函数: oracommon10!sktsfMalloc+c:价值 270.16 MB 的未完成分配。

函数:oracommon10!sktsfMalloc+c

分配类型 C/C++ 运行时分配

分配计数 455 个分配

分配大小 270.16 MB

泄漏概率 95%


从下面的调用堆栈示例(我在最顶级的 .Net 调用之后包含了本机调用),有人可以帮助我理解这一点吗? 我假设这可能是 Oracle 连接之一未关闭的问题。


Function            Source              Destination
oracommon10!sktsfMalloc+c                           msvcr71!malloc 
orageneric10!kghaex+5ef       
ntdll!ZwSetEventBoostPriority+c       
ntdll!RtlpUnWaitCriticalSection+22
OraClient10!kpuinit0+a5c       
OraClient10!kpuenvcr+ea
OraClient10!OCIEnvCreate+3d
oci!OCIEnvCreate+2a
0x1CE2A1F       
mscorwks+3ad8       
System.Data.OracleClient.OciHandle..ctor(System.Data.OracleClient.OciHandle, HTYPE, MODE, HANDLEFLAG)       
System_Data_OracleClient_ni+e1d38       
System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(System.Data.Common.DbConnection, System.Data.ProviderBase.DbConnectionPool, System.Data.Common.DbConnectionOptions)       
System.Data.OracleClient.OracleConnection.Open()       
Microsoft.Practices.EnterpriseLibrary.Data.Database.GetNewOpenConnection()       
Microsoft.Practices.EnterpriseLibrary.Data.Database.GetOpenConnection(Boolean)
Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteReader(System.Data.Common.DbCommand)
Microsoft.Practices.EnterpriseLibrary.Data.Oracle.OracleDatabase.ExecuteReader(System.Data.Common.DbCommand)
MyDAL.MyMethod(System.String, System.String, Int32) 

【问题讨论】:

  • 欢迎来到 StackOverflow。请编辑您问题上的标签以表明您正在使用哪种编程语言(很明显您使用的是 .NET 语言,但在您真正打开问题之前不要这样做,许多可能会回答的人不会打扰)。 memory 没有其他标签是毫无意义的。添加适当的标签有助于人们了解您的问题,并提高您获得答案的机会。
  • 您确定连接正在关闭吗?
  • 很久以前就解决了这个问题,但是忘记在这里更新了。问题在于另一部分代码允许用户通过输入三个或更多字符进行搜索。逻辑中的一个错误,启动了对数据库的调用以从表中获取所有行。当代码被命中时,非托管空间开始填充,私有字节疯狂地飙升,直到应用程序崩溃......

标签: .net oracle memory memory-leaks ado.net


【解决方案1】:

如果你看过这样的帖子,

http://blogs.msdn.com/b/tess/archive/2009/02/03/net-memory-leak-to-dispose-or-not-to-dispose-that-s-the-1-gb-question.aspx

您将看到确定构建完整图像所需的罪魁祸首。泄漏跟踪规则只能帮助您更好地了解非托管资源是如何被吃掉的,但要分析它发生的原因,就需要进行彻底的分析。

我的理解是,

  1. 我们还不能就“一个未关闭的 Oracle 连接”得出结论,因为调用堆栈没有表明这一点。
  2. 没有关于其他线程、托管堆等的所有信息,无法进一步讨论。
  3. 没有 Oracle 符号,从本地也很难分辨。

所以我对您的建议是通过 http://support.microsoft.com 打开支持案例并与 Microsoft 支持团队共享转储。他们在这些问题上有更多的经验。

【讨论】:

  • 谢谢!我一直在关注 Tress 的博客。这个非常好。我能够学到很多东西。还在调查这个问题。当我找到它时会在这里更新..
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-03-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-12-11
  • 1970-01-01
相关资源
最近更新 更多