[ abandoned]Weird memory-leak when using a (unmanaged) DLL

Hi, I'm using a DLL written in c++ (unmanaged).
Using this DLL I'm observing a massive memory-leak, which could be located to the unmanaged HeapMemory (using .Net Memory Profiler).

After doing some tests I figured:
Using the DLL from a console-application, which is just console-printing the information recieved via the CallBack-Functions the memory usage is constant.
Changing it to an WindowForm application and just registering empty CallBack functions the memory usage is constant.

When using the CallBack-functions to create/update objects the meory-leak is present.

Does anybody have an idea/solution on such a problem.

Quote:

---

Originally Posted by opus

When using the CallBack-functions to create/update objects the meory-leak is present.

Does anybody have an idea/solution on such a problem.

---

Can you show this version of the code??

In a module

Code:

---

<UnmangedFunctionPointer(CallingConvention.Cdecl)> Public Delegate DelEntityCallback (ByVal Site As Integer, Byval Application As Integer, ByVal ID As Integer, ByVal Name As String, ByVal Entity_Change As enEntityChange, ByRef UpdateInfo As strucUpdateInfo)

<DLLImport("DIS_LIB.DLL), Entrypoint:= "Set_Entity_Callback", setlasterror:=True, CharSet:= CharSet.ANSI, exactspelling:=True,  CallingConvention:=CallingConvention.CDecl)> _
Public Sub Set_Entity_Callback (ByVal Active as Boolean, ByVal CallBackAddr as DelEntityCallback)
End sub

---

in the "Mainform"- class

Code:

---

Dim cb As DelEntityCallback
Public MyEntities As List (of clEntities)

Private Sub Mainform_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
...
cb= AddressOf  EntityUpdate
...
End Sub


Public Sub EntityUpdate (ByVal Site As Integer, Byval Application As Integer, ByVal ID As Integer, ByVal Name As String, ByVal Entity_Change As enEntityChange, ByRef UpdateInfo As strucUpdateInfo)
Select Case Entity_Change 'Entity_Change is an Enum with 0= New, 1= Update, 2=Delete
  Case is = enEntityChange.New
      MyEntities.Add(New clEntity(Site,Application,ID,UpdateInfo.Position)
  Case Is = enEntityChange.Update
      Dim Index As Integer = MyEntites.FindIndex(Function(f As clEntity) f.ID = ID AndAlso f.Site = Site AndAlso f.Application = Application)
      If Not Index = -1 then
        With MyEntities(Index)
            .Mutex.WaitOne()
            .Position=UpdateInfo.Position
            .Mutex.ReleaseMutex()
        End With
      End If   
  Case Is = enEntityChange.Delete
      Dim Index As Integer = MyEntites.FindIndex(Function(f As clEntity) f.ID = ID AndAlso f.Site = Site AndAlso f.Application = Application)
      If Not Index = -1 then
          MyEntities(Index).Dispose()
          MyEntities(Index)= Nothing
          MyEntities.Remove(MyEntities(Index))
      End If
End Select   
End Sub

---

Forgot one needed line:

Code:

---

Private Sub mnuStartStop_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles mnuStartStop.Click
..
..
Set_Entity_Callback(True, cb)
End Sub

---

A .Net Mutex wraps the OS Mutex which is an unmanaged resource. If that call back is being invoked for many additions then it could be all the Mutexes that are being created for all the new clEntity objects being instantiated. Comment out the code in the Select Case that creates new clEntity objects and see if you're still getting memory leaks. Or if you have the source for the clEntity class, comment out the code that creates the Mutex. We need to eliminate or confirm the Mutexes as the cause.

Thanks for the input.
First trials seems to show the it isn't the Mutex.
I'll continue to search.

Found one mistake in my initial posting, the window application shows a stable memory usage if the .DLL isn't set to an "active state". In that case the Callbacks are not raised. When "active" the .DLL is reading and processing UDP-messages from "somewhere".

I have done more testing and now I'm lost.

The situation:
The .DLL
When "active" the .DLL is reading,sending and processing UDP-messages holding Entity-Information from "somewhere". Entity-Information coming from "somwhere" is sent via CallBacks to my connected application as well as it is recieving Entity Information from my Entites.

My Application is recieving those Remote Entities, is creating own Objects on them or Updating existing ones if they match. Using those Objects a simulation for a number of different sensors is done.

When using the .DLL with my Application I observe an extreme memory leak.

When using the DLL with all the Object-Handing in a Console-Applcation, No Memory Leak. (BTW: using the Mutex as posted above)

When using my Application without the DLL, creating the same number of "Remote Entites", calling the same Functions to update those Entities that were used by the DLL-CallBacks, No Memory Leak.

Where could theoretically be the problem since I covered the use of the unmanaged DLL with a managed ConsoleApplication and I covered the handling and display of the number of Objects (always 1000) in the Forms-Application?
Should I try to "insert" the Forms into the ConsoleApplication (is that possible at all)?

Do you have the code for this unmanaged DLL by any chance ?

Yes, I have access to it.
What should I look for?

Well, I mean you can look at what it does for any clues. Do you know C/C++ ?

Quote:

---

Do you know C/C++ ?

---

Not enough in order to find a mistake in the code. Again, since the use of the DLL in a Console application is showing no memory leak, I'd believe to problem isn't the DLL.
Knowing that a Console Application doesn't show the leak I did put all my code (including the Forms) into such an application and using a "Main" just do .Show my MainForm and keep the console running until this MainForm is closed. Guess what, the isn't gone, however the mmeory increase (for example of Private Bytes) is increasing in 10 minutes "only" by 50% intead of 300%.
What is the difference between an WinForm and a Console Application?

Quote:

---

Originally Posted by opus

What is the difference between an WinForm and a Console Application?

---

Well there are a lot of pluming differences but one of the main differences is that a WinForms app has a message loop and a console app does not. There is also significantly less plumbing in a console app.

Sorry for late reply.
I think I'm giving up on this one.
Using bthe .DLL in a Window Application I get the MemoryLeak even if I only Declare two Methods that do take just a Bool. What mistake could be there?
The workaround using a Console Application that opens my Forms did show a smaller leak, however it was still a leak. The application is supposed to be running for houres, not knowing how much "traffic" is observed.

I'll probably try another way to connect to this "traffic".

Thanks for all the help.

Sorry to hear that. I wish I could have been of more help to you. But I will say this, there's always the risk that using unmanaged code will result in memory leaks.

Don't blame yourself. It is as it is, looking back to the beginning of my project (I joined VBF back then), I wouldn't have dremt of such a stage.
today I have succesfully managed to incooperated a (commercial) interface for a "Tactical Data Link". I learned a lot about implementing a DLL doing that.
The present problem (incooperate the interface to DIS [Distributed Interactive Simulation]) has other possible ways to go along, I'll have a closer look into interfaces that would allow to connect via DIS or HLA(High Level Architecture).

So be assured I'll have more questions to come.