[Mono-dev] Need help tracking this bug...

[Joe Shaw]

Hey,

On 3/30/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> Yup, i had noticed that ;) There is something fishy, but i can't find out
> what it is. I've run heap-shot and attached and emailed the results in
> already. Hopefully they'll make sense to someone. By the looks of it,
> there's some kind of problem internal to mono which is resulting in this
> rapid memory usage as on MS.NET this doesn't happen. There could easily be a
> bug in my own code and MS.NET just handles it better, but i have no idea
> what is causing the problem to start off with, so i can't fix it.

I just took a look at your heap-shot files, and it's a little odd.
Specifically in Second Run/outfile_1.omap:

object[] is the obvious problem.  367 instances, 490 megs, average
size: 1.3 megs.

You have to drill down in the inverse references to find specifically
the big consumer: object[] -> System.Collections.Queue ->
System.Net.Sockets.Socket ->
System.Net.Sockets.Socket/SocketAsyncResult -> object[].  It has 35
instances taking 373 megs, with an average of 10.6 megs each.

That huge object array, in turn, is referenced by
System.Collections.Queue -> System.Net.Socket.Socket, specifically the
readQ member.  So basically it means that the readQ member in
System.Net.Socket.Socket is a huge Queue, which internally has an
object array, which apparently has millions of SocketAsyncResult
objects inside.  So how those are being allocated?

These objects are created a lot, but the ones that create them and
enqueue them into readQ are BeginReceive() and BeginReceiveFrom().
That queue is dequeued inside the Complete() method.  I don't know
much about the Socket class and how the async IO works, but it boils
down to the fact that BeginReceive() is being called probably millions
of times, but it doesn't look like Complete() is being called enough
(or possibly at all) to balance the load.

Hope this helps,
Joe