From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/297 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: malloc testing Date: Thu, 21 Apr 2011 02:00:57 -0400 Message-ID: <20110421060057.GR277@brightrain.aerifal.cx> References: <4DA1D3CC.1090008@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1312595710 11494 80.91.229.12 (6 Aug 2011 01:55:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 01:55:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: envelope-from@hidden Thu Apr 21 10:06:25 2011 Content-Disposition: inline In-Reply-To: <4DAF9259.10300@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:297 Archived-At: On Thu, Apr 21, 2011 at 09:11:37AM +0700, JIghtuse wrote: > On 20.04.2011 11:34, Rich Felker wrote: > >On Sun, Apr 10, 2011 at 10:59:08PM +0700, JIghtuse wrote: > >>I have some questions about my task. I've written a program to test > >>malloc() function of musl. But.. > >Any updates? Are you still interested in working on this? > > > >Ricih > Yes, I interested in. Just some studying. > Can you give some algorithms? I not found its on the Net. How chunks > should be flipped? Try something like: 1. Allocate blocks in random sizes until the total size exceeds the configured limit M. For each block allocated, keep track of its address and size. 2. Sort the allocated block records by size (with the qsort function). 3. Free all but the first 25% in the sorted list (i.e. all but the smallest ones). Leave the ones you don't free in your list. Repeat this procedure a few times, and the last time through, don't free anything. Now sort the records by address instead of by size, and check that they don't overlap. For large allocations (>100k) I would bias the random numbers to be just below a multiple of 4096. Something like: if (size > 100000) size |= 0xff0; This puts them in the "red zone" where bugs could (and in the past did) lead to under-allocation. Rich