On 03/30/07 Alan McGovern wrote:
type=System.MonoType 2826 542.8M 201403.8 0.6
Half a gigabyte of System.MonoType's? What causes these to be allocated, and
what can i do to stop this?
That data must be incorrect. MonoType is fixed-size (16 bytes on 32 bit
systems), so the data is
Hi,
I just compiled the latest SVN head, and once again monotorrent works
perfectly (well, as perfectly as to be expected ;) ). No more crazy memory
usage, which means it was a mono bug after all. I just wish i knew what
exactly had gone wrong inside mono. For the amount of time i spent trying
Hi Alan,
On 3/29/07, Alan McGovern [EMAIL PROTECTED] wrote:
I ran it again, and came up with this (startling ;) ) figures for
allocations:
1) type=System.Runtime.Remoti...ing.MonoMethodMessage 4185
1024.1M 256603.6 0.5
System.Threading.ThreadPool:QueueUserWorkItem
Hi,
On 3/30/07, Miguel de Icaza [EMAIL PROTECTED] wrote:
One question: how do I enable the four different profiling modes for
HeapBuddy?
The summary mode is the default. For the others, you just provide the
relevant word on the command line. history, types, backtraces.
You can also turn off
Hi,
Yep, that's your problem right there. ;) Also, if you look at the
summary you posted, you'll notice that in the course of 1 second, you
have 9 resizes going from a size of 2.8 megs to 322.6 megs.
Yup, i had noticed that ;) There is something fishy, but i can't find out
what it is. I've
Hi Alan,
If you can run your application on Windows, check this tool which can
help to find where's located memory leak:
http://www.microsoft.com/downloads/details.aspx?amp;amp;displaylang=enfamilyid=9bfa49bc-376b-4a54-95aa-73c9156706e7displaylang=en.
This guide can also help:
Just a quick update, i think my email bounced due to the attached heap-shot
data. I'm now hosting it here:
http://www.megaupload.com/?d=QOJKRWT2
If theres problems with that, let me know.
Alan.
On 3/30/07, Marcos Cobeña Morián [EMAIL PROTECTED] wrote:
Hi Alan,
If you can run your
From your e-mail, it seems to be those AsyncSockets not disposing as
expected
Even if i wasn't disposing of them at all, i connect to at most 5 people a
second, so that's at most 5 sockets being created a second. There's no way
that they would lead to such a huge allocation rate. Also, i can
Hi,
I gave that a shot, but i can't actually make use of it :( The problem is
that the memory usage goes from 20 megabytes to 2 gigabytes in the space of
2 seconds. I can't get a snapshot of anywhere in between and once memory
usage rockets up there, i can't take a snapshot using the tool.
So
Hey,
On 3/30/07, Alan McGovern [EMAIL PROTECTED] 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
Hi again,
On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote:
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
Hi,
That leaves me with the question of how the hell a SocketAsyncResult is 10
megs in size! The size of the largest single object in my entire code is a
16kB byte[] buffer. If each SocketAsyncResult is 10 megabytes in size, i
have to question the internal workings of mono, as i know from
Hi,
On 3/30/07, Alan McGovern [EMAIL PROTECTED] wrote:
That leaves me with the question of how the hell a SocketAsyncResult is 10
megs in size!
It's not the SocketAsyncResult itself that's 10 megs in size, it's the
object array that holds them that is 10 megs in size.
I'm going to do a bit
Ok, i did a quick bit of testing on my code.
Firstly, the 54 instances of SocketAsyncResult do make sense. Typically
there will *always* be a pending BeginReceive on every socket i have opened.
Therefore 54 instances of SocketAsyncResult would correspond to 54 open
connections, which is pretty
Hi,
Basically, i have a major (ish) problem in monotorrent with Mono 1.2.1 and
above. After spending a few hours backtracking through svn revisions, i've
managed to place the origin of the problem to between revision 72227 and
72228 of monotorrent in the mono svn.
To generate the diff just use:
Hi Alan,
On 3/29/07, Alan McGovern [EMAIL PROTECTED] wrote:
So, the thing is i can't track down what's causing the memory usage in
monotorrent. I have no idea how to even start. I've tried using the built in
profilers, but they require a graceful exit before they output their data,
and
Hi,
I finally managed to get heap-buddy working on my mac, it took a while, but
i got there ;) After testing monotorrent for a while with the debugger
enabled, nothing happened. Then i realised i wasn't using mono 1.2.3. A few
minutes later i fired up monotorrent using mono 1.2.3 and within
I ran it again, and came up with this (startling ;) ) figures for
allocations:
1) type=System.Runtime.Remoti...ing.MonoMethodMessage 4185 1024.1M 256603.6
0.5
System.Threading.ThreadPool:QueueUserWorkItem
System.Timers.Timer:StartTimer
What the hell? 1 gig of
Hello,
I would use the two external memory profilers for this: heap-buddy and
heap-shot. Both are available from Mono SVN and straightforward to
build and use.
This was a great explanation of what Heap Buddy was, I have added a page
to the Wiki with most of your email:
Hello,
I finally managed to get heap-buddy working on my mac, it took a
while, but i got there ;) After testing monotorrent for a while with
the debugger enabled, nothing happened. Then i realised i wasn't using
mono 1.2.3. A few minutes later i fired up monotorrent using mono
1.2.3 and
20 matches
Mail list logo
