Question

I am debugging OOM issue in ASP.NET web application. Using perfmon counters, identified that there is issue with unmanaged space. So, I used Debugdiag to generate a dump and create a memory pressure analysis report out of it.

---

Summary:

oracommon10.dll is responsible for 270.16 MBytes worth of outstanding allocations.

Top Memory consuming function:
oracommon10!sktsfMalloc+c: 270.16 MBytes worth of outstanding allocations.

Function : oracommon10!sktsfMalloc+c

Allocation type C/C++ runtime allocation(s)

Allocation Count 455 allocation(s)

Allocation Size 270.16 MBytes

Leak Probability 95%

---

From the Call Stack Sample below (I have included the native calls after the top most .Net call), can some one help me understand this?
I am assuming this could be an issue with one of Oracle connections not closed.

---

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) 

Answer 1

If you have read posts like this,

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

You will see to identify the culprit you need to build up a full image. The leak track rule only helps you know better how the unmanaged resources were ate, but to analyze why it happened, a thorough analysis is required.

My understanding is,

1. We could not yet draw a conclusion on “one of Oracle connections not closed”, as the call stack does not indicate that.
2. Without all information about other threads, managed heaps and so on, it is not possible to discuss further.
3. Without Oracle symbols, it is also hard to tell from native side.

So my suggestion to you is to open a support case via http://support.microsoft.com and share the dumps with Microsoft support team. They have more experience on such problems.