malloc testing (was: Simple testing task - string functions)

malloc testing (was: Simple testing task - string functions)

[JIghtuse]

[-- Attachment #1: Type: multipart/alternative, Size: 3494 bytes --]

Re: malloc testing (was: Simple testing task - string

[Rich Felker]

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?

Rich

Re: malloc testing

[JIghtuse]

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?


-- 
Sincerely yours, JIghtuse.

Re: malloc testing

[Rich Felker]

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