#5 malloc error in preparation phase

[Ellert van Koperen]

I ran into a malloc error in the prepare phase of a large puzzle, after which burrgui crashes.
I am running on macosx 10.4.11. with 2GB of ram (1.5 Gb free)
The console gives this:

range optimisation used min 5832, max 5832
burrGui(366,0x203c800) malloc: *** vm_allocate(size=536870912) failed (error code=3)
burrGui(366,0x203c800) malloc: *** error: can't allocate region
burrGui(366,0x203c800) malloc: *** set a breakpoint in szone_error to debug
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc

This happens when the VM usage hits around 2.1 GB.
That it wants to allocate another chunk of 500M is... well large, but should be okay.
I found the following message about this error:
http://gcc.gnu.org/ml/gcc-help/2004-02/msg00232.html
from there i quote: When new fails to allocate the memory for an object, or new[] fails to allocate the memory for an object array, a std::bad_alloc object is thrown. In GCC, the RTTI mangled name of std::bad_alloc is, I'm guessing, St9bad_alloc.

The guy there used ddd to find the malloc/new problem.

I have attached the (unfinished) puzzle i am getting this crash with.

in the xcode documentation i found this, perhaps it helps:
---
Allocating Large Memory Blocks
For allocations greater than a few virtual memory pages, malloc uses the vm_allocate routine to obtain a block of the requested size. The vm_allocate routine assigns an address range to the new block in the virtual memory space of the current process but does not allocate any physical memory. Instead, the malloc routine pages in the memory for the allocated block as it is used.

The granularity of large memory blocks is 4096 bytes, the size of a virtual memory page. If you are allocating a large memory buffer, you should consider making it a multiple of this size.

Note: Large memory allocations are guaranteed to be page-aligned.
For large allocations, you may find that it makes sense to allocate virtual memory using vm_allocate directly. The example in Listing 1 shows how to use the vm_allocate function.

Listing 1 Allocating memory with vm_allocate
void* AllocateVirtualMemory(size_t size)
{
char* data;
kern_return_t err;

// In debug builds, check that we have
// correct VM page alignment
check(size != 0);
check((size % 4096) == 0);

// Allocate directly from VM
err = vm_allocate( (vm_map_t) mach_task_self(),
(vm_address_t*) &data,
size,
VM_FLAGS_ANYWHERE);

// Check errors
check(err == KERN_SUCCESS);
if(err != KERN_SUCCESS)
{
data = NULL;
}

return data;
}

---

If there is anything i can do to help to track this one down, ill be glad to assist.
ps. i got a hint to use setrlimit or ulimit, but i can not find how to use it.

Kind regards,
Ellert.

[Ellert van Koperen]

a puzzle that couses the malloc crash

[Andreas Röver]

BurrTools doesn't contain any memory checks at all. It will simply crash when it can not allocate the required amount of memory. I don't think that I will change that, there are just too many cases to consider.

But in your case you should really think if it would be possible to use 3x3x3 cubes instead of your 6x6x6, or maybe 4x4x4. The holey cubes can be made with both and diagonally cut cubes are mentioned in the manual. 4x4x4 is possible 3x3x3 might be possible.

Andreas

[Ellert van Koperen]

Ok.
I used the 6x6x6 blocks because i need to match a lot of rotation points 1-to-1.
Still odd that allocating 2gb gives a problem, i assume it is mac only, i will give it a spin on a windows machine.

Thanks for your time.