From mattj at google.com Tue Jul 17 19:54:34 2007 From: mattj at google.com (Matt Jones) Date: Tue, 17 Jul 2007 16:54:34 -0700 Subject: [Mono-gc-list] Request for backport of garbage collection patch Message-ID: <904636f60707171654l6dae3535t3640d9c1154db706@mail.gmail.com> Hi - I'm working on improving mono-under-wine (on the wine side), and I've been hitting a bug in the mono garbage collector fixed by commit #77073 ([1]). The bug in question is a race condition between GetExitCodeThread and SuspendThread - if a thread terminates between the two, SuspendThread will fail. The race condition is pretty reliably triggered by the regression test suite when running under wine. The current patch could actually be reduced further (the GetExitCodeThread block could be fully deleted, as it is rendered redundant), but it works as is. Any chance this patch could be applied to the maintenance branch? The patch applies cleanly to 1.13.8.2. Thank you very much, -Matt Jones [1] http://anonsvn.mono-project.com/viewcvs/trunk/mono/libgc/win32_threads.c?rev=77073&view=log From davidiw at ufl.edu Wed Jul 18 08:08:51 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 08:08:51 -0400 Subject: [Mono-gc-list] Mono memory problems! In-Reply-To: <469DA04D.4040307@ufl.edu> References: <469DA04D.4040307@ufl.edu> Message-ID: <469E02D3.4040702@ufl.edu> My lab works on a peer-to-peer network overlay and we've noticed recently significant memory issues. Some background... This application is constantly creating new objects and shortly thereafter deleting (removing reference to) them Using a sample run with 150 threads running... Mono on Linux has a growth rate of ~25 KB per second with a base of 50MB (y = 25K *x + 50M) .NET on Windows stabilizes at 35 MB We ran heap-shot with Linux and found that in a 12 hour period it reported this... start: objects: 58,823 heap memory: 6,838,426 bytes end: objects: 59,925 heap memory: 6,862,336 We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size (RES) got significantly bigger than it. I have searched for the Compacting GC with no luck, we would really like to see if it would help our problem. The only operating system resources we're using are Sockets, but we use them VERY heavily! If anyone has any suggestions, we'd be open to test out anything at this point! We are leaning towards an issue in unmanaged memory and possibly a bug in mono. Best regards, David ps, I fwded this to gc and devel list because gc list looks quite dead.... sorry for the duplication From davidiw at ufl.edu Wed Jul 18 09:06:32 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 09:06:32 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> Message-ID: <469E1058.5030105@ufl.edu> Initially 45 MB, 12 hours later 147 MB Another developer has the heap-shot logs, I'll post those as soon as possible. David Alan McGovern wrote: > Could you post up the detailed stats from heapshot? After the 12 hour > run, how much memory are you using? Are we talking in the gigabyte > range, or megabyte range? > > Alan. > > On 7/18/07, *David Wolinsky* > wrote: > > My lab works on a peer-to-peer network overlay and we've noticed > recently significant memory issues. Some background... > > This application is constantly creating new objects and shortly > thereafter deleting (removing reference to) them > Using a sample run with 150 threads running... > Mono on Linux has a growth rate of ~25 KB per second with a base > of 50MB > (y = 25K *x + 50M) > .NET on Windows stabilizes at 35 MB > > We ran heap-shot with Linux and found that in a 12 hour period it > reported this... > start: > objects: 58,823 > heap memory: 6,838,426 bytes > > end: > objects: 59,925 > heap memory: 6,862,336 > > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size > (RES) got > significantly bigger than it. > > I have searched for the Compacting GC with no luck, we would > really like > to see if it would help our problem. > > The only operating system resources we're using are Sockets, but > we use > them VERY heavily! > > If anyone has any suggestions, we'd be open to test out anything > at this > point! > > We are leaning towards an issue in unmanaged memory and possibly a bug > in mono. > > Best regards, > David > > > ps, I fwded this to gc and devel list because gc list looks quite > dead.... sorry for the duplication > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > From davidiw at ufl.edu Wed Jul 18 11:20:08 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 11:20:08 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> <469E1058.5030105@ufl.edu> <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> Message-ID: <469E2FA8.9050001@ufl.edu> We run this software on system where memory is a concern. The data that we presented is our test case system that has 50 nodes all running in the same mono process. We run only a single node at each site which initially starts at ~15 MB, we've seen it swell to well over 300 MBs in a period of less than a week. Since this must be used in production environments and is meant to be extremely lightweight we can forgive a small memory portion like 15 MB, since it has relatively no processing overhead, but at over 300 MBs our processes are often stopped by the remote admin and we are told to clean up the problem. Since this seems to be a problem of using a non-compacting gc, do you know where the compacting gc is, so that we could at least test it out. I searched the SVN and found no clues of it. Also, I should correct myself, the results for memory consumption were not directly related to the test that grows at 25kB/sec. I found this out after posting the data, I am running heap-shot right now with the correct test and it has grown 100MB in less than 1 hour. Regards, David Alan McGovern wrote: > Well, after 12 hours at a consistent 25kB/sec, you'd expect to have > over 1 gig of memory allocated. As you don't, i think what you're > seeing is just 'normal usage' for the non-compacting GC that mono > uses. I have a similar app which uses sockets extensively (50-150 > simultaneous connections) and i can assure you that memory usage > doesn't get unbearably large. It'd be interesting to see the logs but > i don't think there's much to be worried about. > > Alan. > > On 7/18/07, *David Wolinsky* > wrote: > > Initially 45 MB, 12 hours later 147 MB > > Another developer has the heap-shot logs, I'll post those as soon as > possible. > > David > > Alan McGovern wrote: > > Could you post up the detailed stats from heapshot? After the 12 > hour > > run, how much memory are you using? Are we talking in the gigabyte > > range, or megabyte range? > > > > Alan. > > > > On 7/18/07, *David Wolinsky* > > >> wrote: > > > > My lab works on a peer-to-peer network overlay and we've noticed > > recently significant memory issues. Some background... > > > > This application is constantly creating new objects and shortly > > thereafter deleting (removing reference to) them > > Using a sample run with 150 threads running... > > Mono on Linux has a growth rate of ~25 KB per second with a > base > > of 50MB > > (y = 25K *x + 50M) > > .NET on Windows stabilizes at 35 MB > > > > We ran heap-shot with Linux and found that in a 12 hour > period it > > reported this... > > start: > > objects: 58,823 > > heap memory: 6,838,426 bytes > > > > end: > > objects: 59,925 > > heap memory: 6,862,336 > > > > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size > > (RES) got > > significantly bigger than it. > > > > I have searched for the Compacting GC with no luck, we would > > really like > > to see if it would help our problem. > > > > The only operating system resources we're using are Sockets, but > > we use > > them VERY heavily! > > > > If anyone has any suggestions, we'd be open to test out > anything > > at this > > point! > > > > We are leaning towards an issue in unmanaged memory and > possibly a bug > > in mono. > > > > Best regards, > > David > > > > > > ps, I fwded this to gc and devel list because gc list looks > quite > > dead.... sorry for the duplication > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list at lists.ximian.com > > >

> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > From davidiw at ufl.edu Wed Jul 18 11:44:03 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 11:44:03 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <469E2FA8.9050001@ufl.edu> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> <469E1058.5030105@ufl.edu> <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> <469E2FA8.9050001@ufl.edu> Message-ID: <469E3543.2040801@ufl.edu> We've isolated the problem down to AutoResetEvent... using System; using System.Threading; namespace Ipop { public class IPOP_Common { public static void Main() { AutoResetEvent re = null; while(true) { re = new AutoResetEvent(false); re.Close(); } } } } blows up memory whereas ... using System.Security.Cryptography; using System; namespace Ipop { public class IPOP_Common { public static void Main() { RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); while(true) { byte[] key = new byte[1024]; rng.GetBytes(key); } } } } This doesn't. David Wolinsky wrote: > We run this software on system where memory is a concern. The data that > we presented is our test case system that has 50 nodes all running in > the same mono process. We run only a single node at each site which > initially starts at ~15 MB, we've seen it swell to well over 300 MBs in > a period of less than a week. Since this must be used in production > environments and is meant to be extremely lightweight we can forgive a > small memory portion like 15 MB, since it has relatively no processing > overhead, but at over 300 MBs our processes are often stopped by the > remote admin and we are told to clean up the problem. > > Since this seems to be a problem of using a non-compacting gc, do you > know where the compacting gc is, so that we could at least test it out. > I searched the SVN and found no clues of it. > > Also, I should correct myself, the results for memory consumption were > not directly related to the test that grows at 25kB/sec. I found this > out after posting the data, I am running heap-shot right now with the > correct test and it has grown 100MB in less than 1 hour. > > Regards, > David > > > > Alan McGovern wrote: > >> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have >> over 1 gig of memory allocated. As you don't, i think what you're >> seeing is just 'normal usage' for the non-compacting GC that mono >> uses. I have a similar app which uses sockets extensively (50-150 >> simultaneous connections) and i can assure you that memory usage >> doesn't get unbearably large. It'd be interesting to see the logs but >> i don't think there's much to be worried about. >> >> Alan. >> >> On 7/18/07, *David Wolinsky* > > wrote: >> >> Initially 45 MB, 12 hours later 147 MB >> >> Another developer has the heap-shot logs, I'll post those as soon as >> possible. >> >> David >> >> Alan McGovern wrote: >> > Could you post up the detailed stats from heapshot? After the 12 >> hour >> > run, how much memory are you using? Are we talking in the gigabyte >> > range, or megabyte range? >> > >> > Alan. >> > >> > On 7/18/07, *David Wolinsky* > >> > >> wrote: >> > >> > My lab works on a peer-to-peer network overlay and we've noticed >> > recently significant memory issues. Some background... >> > >> > This application is constantly creating new objects and shortly >> > thereafter deleting (removing reference to) them >> > Using a sample run with 150 threads running... >> > Mono on Linux has a growth rate of ~25 KB per second with a >> base >> > of 50MB >> > (y = 25K *x + 50M) >> > .NET on Windows stabilizes at 35 MB >> > >> > We ran heap-shot with Linux and found that in a 12 hour >> period it >> > reported this... >> > start: >> > objects: 58,823 >> > heap memory: 6,838,426 bytes >> > >> > end: >> > objects: 59,925 >> > heap memory: 6,862,336 >> > >> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size >> > (RES) got >> > significantly bigger than it. >> > >> > I have searched for the Compacting GC with no luck, we would >> > really like >> > to see if it would help our problem. >> > >> > The only operating system resources we're using are Sockets, but >> > we use >> > them VERY heavily! >> > >> > If anyone has any suggestions, we'd be open to test out >> anything >> > at this >> > point! >> > >> > We are leaning towards an issue in unmanaged memory and >> possibly a bug >> > in mono. >> > >> > Best regards, >> > David >> > >> > >> > ps, I fwded this to gc and devel list because gc list looks >> quite >> > dead.... sorry for the duplication >> > _______________________________________________ >> > Mono-devel-list mailing list >> > Mono-devel-list at lists.ximian.com >> >> > > > >> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > >> > >> >> >> > > _______________________________________________ > Mono-gc-list maillist - Mono-gc-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-gc-list > > From davidiw at ufl.edu Wed Jul 18 11:49:29 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 11:49:29 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <469E3543.2040801@ufl.edu> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> <469E1058.5030105@ufl.edu> <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> <469E2FA8.9050001@ufl.edu> <469E3543.2040801@ufl.edu> Message-ID: <469E3689.3030804@ufl.edu> FYI, this case is only triggered when using gmcs and not mcs. David David Wolinsky wrote: > We've isolated the problem down to AutoResetEvent... > > using System; > using System.Threading; > > namespace Ipop { > public class IPOP_Common { > public static void Main() { > AutoResetEvent re = null; > while(true) { > re = new AutoResetEvent(false); > re.Close(); > } > } > } > } > > blows up memory > > whereas ... > > using System.Security.Cryptography; > using System; > > namespace Ipop { > public class IPOP_Common { > public static void Main() { > RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); > while(true) { > byte[] key = new byte[1024]; > rng.GetBytes(key); > } > } > } > } > > This doesn't. > > David Wolinsky wrote: >> We run this software on system where memory is a concern. The data >> that we presented is our test case system that has 50 nodes all >> running in the same mono process. We run only a single node at each >> site which initially starts at ~15 MB, we've seen it swell to well >> over 300 MBs in a period of less than a week. Since this must be >> used in production environments and is meant to be extremely >> lightweight we can forgive a small memory portion like 15 MB, since >> it has relatively no processing overhead, but at over 300 MBs our >> processes are often stopped by the remote admin and we are told to >> clean up the problem. >> >> Since this seems to be a problem of using a non-compacting gc, do you >> know where the compacting gc is, so that we could at least test it >> out. I searched the SVN and found no clues of it. >> >> Also, I should correct myself, the results for memory consumption >> were not directly related to the test that grows at 25kB/sec. I >> found this out after posting the data, I am running heap-shot right >> now with the correct test and it has grown 100MB in less than 1 hour. >> >> Regards, >> David >> >> >> >> Alan McGovern wrote: >> >>> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have >>> over 1 gig of memory allocated. As you don't, i think what you're >>> seeing is just 'normal usage' for the non-compacting GC that mono >>> uses. I have a similar app which uses sockets extensively (50-150 >>> simultaneous connections) and i can assure you that memory usage >>> doesn't get unbearably large. It'd be interesting to see the logs >>> but i don't think there's much to be worried about. >>> >>> Alan. >>> >>> On 7/18/07, *David Wolinsky* >> > wrote: >>> >>> Initially 45 MB, 12 hours later 147 MB >>> >>> Another developer has the heap-shot logs, I'll post those as >>> soon as >>> possible. >>> >>> David >>> >>> Alan McGovern wrote: >>> > Could you post up the detailed stats from heapshot? After the 12 >>> hour >>> > run, how much memory are you using? Are we talking in the >>> gigabyte >>> > range, or megabyte range? >>> > >>> > Alan. >>> > >>> > On 7/18/07, *David Wolinsky* >> >>> > >> wrote: >>> > >>> > My lab works on a peer-to-peer network overlay and we've >>> noticed >>> > recently significant memory issues. Some background... >>> > >>> > This application is constantly creating new objects and >>> shortly >>> > thereafter deleting (removing reference to) them >>> > Using a sample run with 150 threads running... >>> > Mono on Linux has a growth rate of ~25 KB per second with a >>> base >>> > of 50MB >>> > (y = 25K *x + 50M) >>> > .NET on Windows stabilizes at 35 MB >>> > >>> > We ran heap-shot with Linux and found that in a 12 hour >>> period it >>> > reported this... >>> > start: >>> > objects: 58,823 >>> > heap memory: 6,838,426 bytes >>> > >>> > end: >>> > objects: 59,925 >>> > heap memory: 6,862,336 >>> > >>> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory >>> size >>> > (RES) got >>> > significantly bigger than it. >>> > >>> > I have searched for the Compacting GC with no luck, we would >>> > really like >>> > to see if it would help our problem. >>> > >>> > The only operating system resources we're using are >>> Sockets, but >>> > we use >>> > them VERY heavily! >>> > >>> > If anyone has any suggestions, we'd be open to test out >>> anything >>> > at this >>> > point! >>> > >>> > We are leaning towards an issue in unmanaged memory and >>> possibly a bug >>> > in mono. >>> > >>> > Best regards, >>> > David >>> > >>> > >>> > ps, I fwded this to gc and devel list because gc list looks >>> quite >>> > dead.... sorry for the duplication >>> > _______________________________________________ >>> > Mono-devel-list mailing list >>> > Mono-devel-list at lists.ximian.com >>> >>> > >> > >>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> > >>> > >>> >>> >>> >> >> _______________________________________________ >> Mono-gc-list maillist - Mono-gc-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-gc-list >> >> > > From davidiw at ufl.edu Wed Jul 18 13:54:49 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 13:54:49 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <1184774762.5420.27.camel@erandi.dom> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> <469E1058.5030105@ufl.edu> <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> <469E2FA8.9050001@ufl.edu> <469E3543.2040801@ufl.edu> <1184774762.5420.27.camel@erandi.dom> Message-ID: <469E53E9.9020106@ufl.edu> That case leaks as well. Regards, David Miguel de Icaza wrote: >> namespace Ipop { >> public class IPOP_Common { >> public static void Main() { >> AutoResetEvent re = null; >> while(true) { >> re = new AutoResetEvent(false); >> re.Close(); >> } >> } >> } >> } >> >> blows up memory >> > > That depends on the finalizer to run to release memory from the > unmanaged side, since AutoResetEvent implements IDisposable you should > use it like this: > > using (re = AutoResetEvent (false)) { > ... > > Miguel > >> whereas ... >> >> using System.Security.Cryptography; >> using System; >> >> namespace Ipop { >> public class IPOP_Common { >> public static void Main() { >> RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); >> while(true) { >> byte[] key = new byte[1024]; >> rng.GetBytes(key); >> } >> } >> } >> } >> >> This doesn't. >> >> David Wolinsky wrote: >> >>> We run this software on system where memory is a concern. The data that >>> we presented is our test case system that has 50 nodes all running in >>> the same mono process. We run only a single node at each site which >>> initially starts at ~15 MB, we've seen it swell to well over 300 MBs in >>> a period of less than a week. Since this must be used in production >>> environments and is meant to be extremely lightweight we can forgive a >>> small memory portion like 15 MB, since it has relatively no processing >>> overhead, but at over 300 MBs our processes are often stopped by the >>> remote admin and we are told to clean up the problem. >>> >>> Since this seems to be a problem of using a non-compacting gc, do you >>> know where the compacting gc is, so that we could at least test it out. >>> I searched the SVN and found no clues of it. >>> >>> Also, I should correct myself, the results for memory consumption were >>> not directly related to the test that grows at 25kB/sec. I found this >>> out after posting the data, I am running heap-shot right now with the >>> correct test and it has grown 100MB in less than 1 hour. >>> >>> Regards, >>> David >>> >>> >>> >>> Alan McGovern wrote: >>> >>> >>>> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have >>>> over 1 gig of memory allocated. As you don't, i think what you're >>>> seeing is just 'normal usage' for the non-compacting GC that mono >>>> uses. I have a similar app which uses sockets extensively (50-150 >>>> simultaneous connections) and i can assure you that memory usage >>>> doesn't get unbearably large. It'd be interesting to see the logs but >>>> i don't think there's much to be worried about. >>>> >>>> Alan. >>>> >>>> On 7/18/07, *David Wolinsky* >>> > wrote: >>>> >>>> Initially 45 MB, 12 hours later 147 MB >>>> >>>> Another developer has the heap-shot logs, I'll post those as soon as >>>> possible. >>>> >>>> David >>>> >>>> Alan McGovern wrote: >>>> > Could you post up the detailed stats from heapshot? After the 12 >>>> hour >>>> > run, how much memory are you using? Are we talking in the gigabyte >>>> > range, or megabyte range? >>>> > >>>> > Alan. >>>> > >>>> > On 7/18/07, *David Wolinsky* >>> >>>> > >> wrote: >>>> > >>>> > My lab works on a peer-to-peer network overlay and we've noticed >>>> > recently significant memory issues. Some background... >>>> > >>>> > This application is constantly creating new objects and shortly >>>> > thereafter deleting (removing reference to) them >>>> > Using a sample run with 150 threads running... >>>> > Mono on Linux has a growth rate of ~25 KB per second with a >>>> base >>>> > of 50MB >>>> > (y = 25K *x + 50M) >>>> > .NET on Windows stabilizes at 35 MB >>>> > >>>> > We ran heap-shot with Linux and found that in a 12 hour >>>> period it >>>> > reported this... >>>> > start: >>>> > objects: 58,823 >>>> > heap memory: 6,838,426 bytes >>>> > >>>> > end: >>>> > objects: 59,925 >>>> > heap memory: 6,862,336 >>>> > >>>> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size >>>> > (RES) got >>>> > significantly bigger than it. >>>> > >>>> > I have searched for the Compacting GC with no luck, we would >>>> > really like >>>> > to see if it would help our problem. >>>> > >>>> > The only operating system resources we're using are Sockets, but >>>> > we use >>>> > them VERY heavily! >>>> > >>>> > If anyone has any suggestions, we'd be open to test out >>>> anything >>>> > at this >>>> > point! >>>> > >>>> > We are leaning towards an issue in unmanaged memory and >>>> possibly a bug >>>> > in mono. >>>> > >>>> > Best regards, >>>> > David >>>> > >>>> > >>>> > ps, I fwded this to gc and devel list because gc list looks >>>> quite >>>> > dead.... sorry for the duplication >>>> > _______________________________________________ >>>> > Mono-devel-list mailing list >>>> > Mono-devel-list at lists.ximian.com >>>> >>>> > >>> > >>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list >>>> > >>>> > >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Mono-gc-list maillist - Mono-gc-list at lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-gc-list >>> >>> >>> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list at lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> > > From davidiw at ufl.edu Wed Jul 18 16:30:54 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 16:30:54 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <0E3D1F5F-3535-40CF-8B71-CF037B6730EB@web.de> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> <469E1058.5030105@ufl.edu> <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> <469E2FA8.9050001@ufl.edu> <469E3543.2040801@ufl.edu> <1184774762.5420.27.camel@erandi.dom> <469E53E9.9020106@ufl.edu> <0E3D1F5F-3535-40CF-8B71-CF037B6730EB@web.de> Message-ID: <469E787E.7000902@ufl.edu> In fact, I was able to fix the problem. For some reason in WaitHandle.cs, the line... safe_wait_handle = new SafeWaitHandle (value, false); should be... safe_wait_handle = new SafeWaitHandle (value, true); (at least it makes sense according to other docs I read)... second... in SafeWaitHandle.cs, the line ... NativeEventCalls.CloseEvent_internal (DangerousGetHandle()); should be... NativeEventCalls.CloseEvent_internal (handle); The second one is kind of silly because Release gets called only after refcount == 0, but calling DangerousGetHandle throws an exception if refcount == 0. I think there is still a problem of the array of wapi handles not being shrunk down, but that complexity is beyond me. Regards, David Andreas F?rber wrote: > > Am 18.07.2007 um 19:54 schrieb David Wolinsky: > >> That case leaks as well. >> >> Regards, >> David >> >> Miguel de Icaza wrote: >>>> re = new AutoResetEvent(false); >>>> re.Close(); >>> >>> That depends on the finalizer to run to release memory from the >>> unmanaged side, since AutoResetEvent implements IDisposable you should >>> use it like this: >>> >>> using (re = AutoResetEvent (false)) { >>> ... > > Doesn't Close() call Dispose()? At least for the Stream classes it > should. > > Andreas > From davidiw at ufl.edu Wed Jul 18 17:16:59 2007 From: davidiw at ufl.edu (David Wolinsky) Date: Wed, 18 Jul 2007 17:16:59 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <0E3D1F5F-3535-40CF-8B71-CF037B6730EB@web.de> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu> <117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com> <469E1058.5030105@ufl.edu> <117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com> <469E2FA8.9050001@ufl.edu> <469E3543.2040801@ufl.edu> <1184774762.5420.27.camel@erandi.dom> <469E53E9.9020106@ufl.edu> <0E3D1F5F-3535-40CF-8B71-CF037B6730EB@web.de> Message-ID: <469E834B.2060909@ufl.edu> Bugzilla report and patch Regards, David http://bugzilla.ximian.com/show_bug.cgi?id=82134 From davidiw at ufl.edu Wed Jul 18 01:08:29 2007 From: davidiw at ufl.edu (David Isaac Wolinsky) Date: Wed, 18 Jul 2007 01:08:29 -0400 Subject: [Mono-gc-list] Mono memory problems! Message-ID: <469DA04D.4040307@ufl.edu> My lab works on a peer-to-peer network overlay and we've noticed recently significant memory issues. Some background... This application is constantly creating new objects and shortly thereafter deleting (removing reference to) them Using a sample run with 150 threads running... Mono on Linux has a growth rate of ~25 KB per second with a base of 50MB (y = 25K *x + 50M) .NET on Windows stabilizes at 35 MB We ran heap-shot with Linux and found that in a 12 hour period it reported this... start: objects: 58,823 heap memory: 6,838,426 bytes end: objects: 59,925 heap memory: 6,862,336 We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size (RES) got significantly bigger than it. I have searched for the Compacting GC with no luck, we would really like to see if it would help our problem. The only operating system resources we're using are Sockets, but we use them VERY heavily! If anyone has any suggestions, we'd be open to test out anything at this point! We are leaning towards an issue in unmanaged memory and possibly a bug in mono. Best regards, David ps, I fwded this to gc and devel list because gc list looks quite dead.... sorry for the duplication From lupus at ximian.com Tue Jul 24 09:43:48 2007 From: lupus at ximian.com (Paolo Molaro) Date: Tue, 24 Jul 2007 15:43:48 +0200 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <01d801c7cdf2$64958a10$1b36a8c0@PROG159> References: <469DA04D.4040307@ufl.edu> <1184804192.5420.91.camel@erandi.dom> <01d801c7cdf2$64958a10$1b36a8c0@PROG159> Message-ID: <20070724134348.GO11258@debian.org> On 07/24/07 Jonathan Gagnon wrote: > I'm pretty sure that this will fix bug #81727 that I filed a few months ago, > although I don't have time to test it for the moment. Thanks, confirmed that issue is fixed as well. lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From jonathan.gagnon at croesus.com Tue Jul 24 08:58:49 2007 From: jonathan.gagnon at croesus.com (Jonathan Gagnon) Date: Tue, 24 Jul 2007 08:58:49 -0400 Subject: [Mono-gc-list] [Mono-dev] Mono memory problems! In-Reply-To: <1184804192.5420.91.camel@erandi.dom> References: <469DA04D.4040307@ufl.edu> <469E02D3.4040702@ufl.edu><117799f00707180603w2be7fcd1k25f5bd293c2ca989@mail.gmail.com><469E1058.5030105@ufl.edu><117799f00707180750ge717ee4g304e7a4807e24bc9@mail.gmail.com><469E2FA8.9050001@ufl.edu> <469E3543.2040801@ufl.edu><1184774762.5420.27.camel@erandi.dom> <469E53E9.9020106@ufl.edu><0E3D1F5F-3535-40CF-8B71-CF037B6730EB@web.de><469E787E.7000902@ufl.edu> <1184804192.5420.91.camel@erandi.dom> Message-ID: <01d801c7cdf2$64958a10$1b36a8c0@PROG159> I'm pretty sure that this will fix bug #81727 that I filed a few months ago, although I don't have time to test it for the moment. Jonathan Gagnon -----Message d'origine----- De : mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] De la part de Miguel de Icaza Envoy? : Wednesday, July 18, 2007 8:17 PM ? : David Wolinsky Cc : Andreas F?rber; Peer-to-peer networking group discussions; mono-gc-list at lists.ximian.com; mono-devel Objet : Re: [Mono-dev] [Mono-gc-list] Mono memory problems! Hello folks, Thanks for tracking this problem down. Thanks for pointing out the comment in the source code; I went and re-read the documentation and I clearly did not understand it the first time over, because the leak was documented to happen only in the .NET 1.0 and 1.1 scenarios, not on the 2.0 scenario. So the fix that takes ownership is correct. I tidied up the patch a little bit as well. The fix is now on svn, thanks again for tracking this down. > In fact, I was able to fix the problem. > > For some reason in WaitHandle.cs, the line... > safe_wait_handle = new SafeWaitHandle (value, false); should be... > safe_wait_handle = new SafeWaitHandle (value, true); (at least it > makes sense according to other docs I read)... > > second... in SafeWaitHandle.cs, the line ... > NativeEventCalls.CloseEvent_internal > (DangerousGetHandle()); should be... > NativeEventCalls.CloseEvent_internal (handle); > > The second one is kind of silly because Release gets called only after > refcount == 0, but calling DangerousGetHandle throws an exception if > refcount == 0. > > I think there is still a problem of the array of wapi handles not > being shrunk down, but that complexity is beyond me. > > Regards, > David > > Andreas F?rber wrote: > > > > Am 18.07.2007 um 19:54 schrieb David Wolinsky: > > > >> That case leaks as well. > >> > >> Regards, > >> David > >> > >> Miguel de Icaza wrote: > >>>> re = new AutoResetEvent(false); > >>>> re.Close(); > >>> > >>> That depends on the finalizer to run to release memory from the > >>> unmanaged side, since AutoResetEvent implements IDisposable you > >>> should use it like this: > >>> > >>> using (re = AutoResetEvent (false)) { > >>> ... > > > > Doesn't Close() call Dispose()? At least for the Stream classes it > > should. > > > > Andreas > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list at lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list From lupus at ximian.com Thu Jul 26 05:13:39 2007 From: lupus at ximian.com (Paolo Molaro) Date: Thu, 26 Jul 2007 11:13:39 +0200 Subject: [Mono-gc-list] [Mono-dev] Request for backport of garbage collection patch In-Reply-To: <904636f60707171654l6dae3535t3640d9c1154db706@mail.gmail.com> References: <904636f60707171654l6dae3535t3640d9c1154db706@mail.gmail.com> Message-ID: <20070726091339.GZ11258@debian.org> On 07/17/07 Matt Jones wrote: > I'm working on improving mono-under-wine (on the wine side), and I've [...] > Any chance this patch could be applied to the maintenance branch? The > patch applies cleanly to 1.13.8.2. I really hope you're not basing your improvements on mono 1.13.x: it is a really old release which nobody should use at this time (especially not to build something new like wine support upon it). Use mono version 1.2.4 (or the upcoming 1.2.5). lupus -- ----------------------------------------------------------------- lupus at debian.org debian/rules lupus at ximian.com Monkeys do it better From mattj at google.com Thu Jul 26 14:29:57 2007 From: mattj at google.com (Matt Jones) Date: Thu, 26 Jul 2007 11:29:57 -0700 Subject: [Mono-gc-list] [Mono-dev] Request for backport of garbage collection patch In-Reply-To: <20070726091339.GZ11258@debian.org> References: <904636f60707171654l6dae3535t3640d9c1154db706@mail.gmail.com> <20070726091339.GZ11258@debian.org> Message-ID: <904636f60707261129k14dcfa9fp33c9400f709a57c1@mail.gmail.com> On 7/26/07, Paolo Molaro wrote: > On 07/17/07 Matt Jones wrote: > > I'm working on improving mono-under-wine (on the wine side), and I've > [...] > > Any chance this patch could be applied to the maintenance branch? The > > patch applies cleanly to 1.13.8.2. > > I really hope you're not basing your improvements on mono 1.13.x: it > is a really old release which nobody should use at this time > (especially not to build something new like wine support upon it). > Use mono version 1.2.4 (or the upcoming 1.2.5). Right. The problem is that mono 1.2 fails horribly under wine, whereas mono 1.1 works pretty well. I'm working on getting mono 1.2 to run under wine, but having a fully-functional 1.1 runtime would help. The intention is not to stick with 1.1.*, but use it until wine can successfully host a 1.2 runtime. matt From miguel at novell.com Mon Jul 30 11:33:38 2007 From: miguel at novell.com (Miguel de Icaza) Date: Mon, 30 Jul 2007 11:33:38 -0400 Subject: [Mono-gc-list] [Mono-dev] Request for backport of garbage collection patch In-Reply-To: <904636f60707261129k14dcfa9fp33c9400f709a57c1@mail.gmail.com> References: <904636f60707171654l6dae3535t3640d9c1154db706@mail.gmail.com> <20070726091339.GZ11258@debian.org> <904636f60707261129k14dcfa9fp33c9400f709a57c1@mail.gmail.com> Message-ID: <1185809618.4675.2.camel@erandi.dom> > Right. The problem is that mono 1.2 fails horribly under wine, whereas > mono 1.1 works pretty well. I'm working on getting mono 1.2 to run > under wine, but having a fully-functional 1.1 runtime would help. It would be interesting to know how Mono 1.2 fails with Wine, there is not much in this email that we can act on. > The intention is not to stick with 1.1.*, but use it until wine can > successfully host a 1.2 runtime. > > matt > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list at lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list