October 25, 2016 Bug in std.allocator? | ||||
---|---|---|---|---|
| ||||
Please consider the following program: import std.experimental.allocator.mallocator; import std.experimental.allocator.building_blocks.allocator_list : AllocatorList; import std.experimental.allocator.building_blocks.free_list; import std.experimental.allocator; import std.stdio; enum uint size = 1104; alias ScalableFreeList = AllocatorList!((n) => ContiguousFreeList!(Mallocator, 0, unbounded)(size * 128, size) ); void main(string[] args) { void[][20] allocs; ScalableFreeList allocator; for(int i=0; i < 100; i++) { writefln("pass %d", i); foreach(ref alloc; allocs) { alloc = allocator.allocate(size); writefln("%x", alloc.ptr); } foreach(alloc; allocs) { allocator.deallocate(alloc); } } } I would assume that this program should run forever and never run out of memory. But instead it triggers an assert inside alocator_list in pass 11. So I assume this is some bug in std.allocator? Also whats interresting. The first allocation in each new pass is _not_ the last allocation to be freed. Instead it seems to "leak" one allocation each pass. From the output of the program: 229a290fd60 <- same 229a2932570 <- leaked? pass 11 229a290fd60 <- same Or can anyone see a bug in my program? Kind Regards Benjamin Thaut |
October 25, 2016 Re: Bug in std.allocator? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Benjamin Thaut | On 10/25/2016 11:30 AM, Benjamin Thaut wrote: > Please consider the following program: [...] > I would assume that this program should run forever and never run out of > memory. But instead it triggers an assert inside alocator_list in pass > 11. So I assume this is some bug in std.allocator? I can confirm the crash with 2.071.2. But it doesn't happen with 2.072.0-b2. So, bug that has already been fixed? > Also whats interresting. The first allocation in each new pass is _not_ > the last allocation to be freed. Instead it seems to "leak" one > allocation each pass. > > From the output of the program: > > 229a290fd60 <- same > 229a2932570 <- leaked? > pass 11 > 229a290fd60 <- same Also looks ok with 2.072.0-b2: 7f448c7ccdb0 7f448c7cd200 pass 99 7f448c7cd200 7f448c7ccdb0 |
Copyright © 1999-2021 by the D Language Foundation