memory leaks in Microsoft.FSharp.Control.Mailbox?

Question

I'm hunting for some memory-leaks in a long runing service (using F#) right now. The only "strange" thing I've seen so far is the following:

• I use a MailboxProcessor in a subsystem with an algebraic-datatype named QueueChannelCommands (more or less a bunch of Add/Get commands - some with AsyncReplyChannels attached)
• when I profile the service (using Ants Memory Profiler) I see instances of arrays of mentioned type (most having lenght 4, but growing) - all empty (null) whose references seems to be held by Control.Mailbox:

I cannot see any reason in my code for this behaviour (your standard code you can find in every Mailbox-example out there - just a loop with a let! = receive and a match to follow ended with a return! loop()

Has anyone seen this kind of behaviour before or even knows how to handle this? Or is this even a (known) bug?

Update: the growing of the arrays is really strange - seems like there is additional space appended without beeing used properly:

Dictatorial

the array seems to be the internal "mailbox.arrivals" of the MailboxProcessor if this is of any help – Dictatorial

Dave Thomas noticed a similar behaviour when he used return! loop() in side a try/catch block: moiraesoftware.com/blog/2011/12/11/fixing-a-hole . I don't think it is the case with your program. – Suntan

yes thank you - I'm aware of this issue, but this resulted in much more overhead (he found a lot Async-stuff), similar to when do! instead of return! is used - here I only see growing, empty arrays without any async-problems. – Dictatorial

Can you give some code that reproduces the problem? – Klement

I will try to get a simple example for this - but it's not on top of my priority list right now so it might take a while - sorry – Dictatorial

After looking through a profiling session of 24hours on the productive service, the main-problem seems to be another one (see here: #9373988) - I formerly tested this only for a couple of minutes-to about 1 hour on my test-machine and only had a look at objects with source (so the stuff I did on my own). In the big picture the arrays seem to grow a bit (and I still don't think that there will be up to 300 messages on one processor at a time) but those kb don't matter against the MB of those pescy byte[] stuff ... sorry! – Dictatorial

in the end this and all the other memory-performance issues I collected at around the time of this post seemed to be caused by a on-screen-keyboard software. After deactivating this and calling DoEvents from time to time (no kidding) all memory-leaks are gone - seems like there is some kind of bug that blocks the finalizer-thread if the oskb is running. Now the problem is that I don't really know what to do with this question - shall I delete it or is this a good clue for other people having the same issues? - What do you think? – Dictatorial

Just in case you don't see my flag response, please do write up your findings in an answer and accept it. I'm sure someone out there may be tearing their hair out with the same problem sometime :) – Quotha

Answer 1

I am not a F# expert by any means but maybe you can look at the first answer in this thread:

Does Async.StartChild have a memory leak?

The first reply mentions a tutorial for memory profiling on the following page:

• http://moiraesoftware.com/blog/2011/12/11/fixing-a-hole/

But they mention this open source version of F#

• https://github.com/fsharp/fsharp/blob/master/src/fsharp/FSharp.Core/control.fs

And I am not sure it is what you are looking for (about this open source version of F# in the last point), but maybe it can help you to find the source of the leak or prove that it is actually leaking memory.

Hope that helps somehow maybe ?

Tony

Porker

Answer 2

.NET has its own garbage collector, which works quite nicely. The most common way to cause memory leaks in .NET technologies is by setting up delegates, and not removing them on object deconstructors.

Fumigant

I think it's fairly to safe to assume that the question asker knows these, judging from the question. Also, your answer has nothing to do with the MailboxProcessor, and even less to the specific problem (arrays and their growth). – Ammamaria

Indeed I do plus: if the implementation of MailboxProcessor doesn't do than nobody wires any events (I guess thats what is meant) here – Dictatorial

This was just a small comment about memory-leak management in .NET. – Fumigant

This was just a small comment about memory-leak management in .NET. Sorry if it didn't help much, but maybe you're hunting for memory leaks with the wrong weapons. Maybe you are allocating memory on delegate-like methods, and that memory does not get deallocated when you destroy those objects. I'm not a fan of F#, so I don't know the insisdes of it, but I did my fair share of mem-leak hunting, and .NET things were always leak-free, if I didn't allocate memory on delegate-like methods. – Fumigant