From wagner at elego.de Sat Apr 19 10:52:12 2014 From: wagner at elego.de (Olaf Wagner) Date: Sat, 19 Apr 2014 10:52:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20140419085212.66A5B5DECF8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 14/04/19 10:52:12 Modified files: cm3/doc/help/: bib.html concise-bib.html Log message: add article from Paul Vixie From hosking at elego.de Tue Apr 29 22:33:09 2014 From: hosking at elego.de (Antony Hosking) Date: Tue, 29 Apr 2014 22:33:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20140429203309.CFE0D5DED7D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 14/04/29 22:33:09 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: Don't grey filler objects, especially for zeroed pages, so as to avoid race with allocation, as follows: On Apr 29, 2014, at 1:10 AM, Peter McKinna wrote: I think there's a small problem with the M3 Collector and I thought I'd run it past you. I have a fix but I'm not sure if its the correct way to go. If you're already aware of this problem please disregard this mail. When the allocator is under heavy load from a number of threads its possible that several threads are blocked in LockHeap inside AllocTraced. When LongAlloc returns (in the single running thread) with its newly zeroed page it enters the finally clause to unlock the heap. At that point another thread can run and relock the heap before the new pointer can return and be initialised. The other thread will then do a collection and promote the page of the newly allocated pointer. The problem is that during the collection both GrayBetween and CleanBetween get called which loop over all objects in that page. Since the typecode of Fill_1_type is zero these procedures treat all zero words as Fill_1_type types and ignore them except to set the dirty and gray flags. At the end of CleanBetween the gray flag is false but the dirty flag is true leaving a page full of 16_200000 values. When the original thread gets control back it returns a pointer to a non zero bunch of memory which is then initialised to some type. This can then lead to a segv if its an object containing references which are then dereferenced. From wagner at elego.de Sat Apr 19 10:52:12 2014 From: wagner at elego.de (Olaf Wagner) Date: Sat, 19 Apr 2014 10:52:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20140419085212.66A5B5DECF8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 14/04/19 10:52:12 Modified files: cm3/doc/help/: bib.html concise-bib.html Log message: add article from Paul Vixie From hosking at elego.de Tue Apr 29 22:33:09 2014 From: hosking at elego.de (Antony Hosking) Date: Tue, 29 Apr 2014 22:33:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20140429203309.CFE0D5DED7D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 14/04/29 22:33:09 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: Don't grey filler objects, especially for zeroed pages, so as to avoid race with allocation, as follows: On Apr 29, 2014, at 1:10 AM, Peter McKinna wrote: I think there's a small problem with the M3 Collector and I thought I'd run it past you. I have a fix but I'm not sure if its the correct way to go. If you're already aware of this problem please disregard this mail. When the allocator is under heavy load from a number of threads its possible that several threads are blocked in LockHeap inside AllocTraced. When LongAlloc returns (in the single running thread) with its newly zeroed page it enters the finally clause to unlock the heap. At that point another thread can run and relock the heap before the new pointer can return and be initialised. The other thread will then do a collection and promote the page of the newly allocated pointer. The problem is that during the collection both GrayBetween and CleanBetween get called which loop over all objects in that page. Since the typecode of Fill_1_type is zero these procedures treat all zero words as Fill_1_type types and ignore them except to set the dirty and gray flags. At the end of CleanBetween the gray flag is false but the dirty flag is true leaving a page full of 16_200000 values. When the original thread gets control back it returns a pointer to a non zero bunch of memory which is then initialised to some type. This can then lead to a segv if its an object containing references which are then dereferenced. From wagner at elego.de Sat Apr 19 10:52:12 2014 From: wagner at elego.de (Olaf Wagner) Date: Sat, 19 Apr 2014 10:52:12 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20140419085212.66A5B5DECF8@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: wagner at birch. 14/04/19 10:52:12 Modified files: cm3/doc/help/: bib.html concise-bib.html Log message: add article from Paul Vixie From hosking at elego.de Tue Apr 29 22:33:09 2014 From: hosking at elego.de (Antony Hosking) Date: Tue, 29 Apr 2014 22:33:09 () Subject: [M3commit] CVS Update: cm3 Message-ID: <20140429203309.CFE0D5DED7D@birch.elegosoft.com> CVSROOT: /usr/cvs Changes by: hosking at birch. 14/04/29 22:33:09 Modified files: cm3/m3-libs/m3core/src/runtime/common/: RTCollector.m3 Log message: Don't grey filler objects, especially for zeroed pages, so as to avoid race with allocation, as follows: On Apr 29, 2014, at 1:10 AM, Peter McKinna wrote: I think there's a small problem with the M3 Collector and I thought I'd run it past you. I have a fix but I'm not sure if its the correct way to go. If you're already aware of this problem please disregard this mail. When the allocator is under heavy load from a number of threads its possible that several threads are blocked in LockHeap inside AllocTraced. When LongAlloc returns (in the single running thread) with its newly zeroed page it enters the finally clause to unlock the heap. At that point another thread can run and relock the heap before the new pointer can return and be initialised. The other thread will then do a collection and promote the page of the newly allocated pointer. The problem is that during the collection both GrayBetween and CleanBetween get called which loop over all objects in that page. Since the typecode of Fill_1_type is zero these procedures treat all zero words as Fill_1_type types and ignore them except to set the dirty and gray flags. At the end of CleanBetween the gray flag is false but the dirty flag is true leaving a page full of 16_200000 values. When the original thread gets control back it returns a pointer to a non zero bunch of memory which is then initialised to some type. This can then lead to a segv if its an object containing references which are then dereferenced.