Allocate memory
#include <stdlib.h> void* malloc( size_t size );
libc
Use the -l c option to qcc to link against this library. This library is usually included automatically.
The malloc() function allocates a buffer of size bytes. Use free() or realloc() to free the block of memory.
If size is zero, the default behavior is to return a non-NULL pointer that's valid only to a corresponding call to free() or realloc(). Don't assume that this pointer points to any valid memory. You can control this behavior via the MALLOC_OPTIONS environmental variable; if the value of MALLOC_OPTIONS contains a V, malloc() returns a NULL pointer. This environment variable also affects calloc() and realloc(). This is known as the “System V” behavior.
If there isn't a free block of memory that's large enough to satisfy the request, the memory allocator uses mmap() to get memory from the system. The _amblksiz global variable (defined in <stdlib.h>) specifies the number of bytes that the allocator gets from the system. You can also use the mallopt() function to control how the system allocates memory. |
A pointer to the start of the allocated memory, or NULL if an error occurred (errno is set).
#include <stdlib.h> int main( void ) { char* buffer; buffer = (char* )malloc( 80 ); if( buffer != NULL ) { /* do something with the buffer */ … free( buffer ); } return EXIT_SUCCESS; }
You can modify the allocator characteristics by setting the following environment variables, which control how memory is cached by the allocator, and when it's released back to the system:
By default, this is set to 32 KB, which results in a minimum allocation of 64 KB by the allocator. You can lower this as long as it's a multiple of the page size (4096). The allocator will still attempt to get memory from the system in multiples of this value, and since it creates buckets of varying sizes, it may choose to allocate core memory for a bucket of blocks of a new size, even though an earlier allocation of core memory for a block of a different size hasn't been fully exhausted.
Memory in the allocator is allocated with different policies for blocks smaller than 128 bytes and blocks larger than 128 bytes:
So, for example, if you make a simple pair of allocations such as:
malloc(100); malloc(200);
the system creates a 32 KB arena allocation for the bucket size of 128 bytes to service the 100-byte allocation, and a 32 KB arena allocation to service the 200-byte allocation.
Lowering MALLOC_ARENA_SIZE can reduce the amount of memory required.
There also other ways to control the exact distribution of sizes used to create small bands of memory and the threshold at which the smaller buckets end and the list-based allocator for larger blocks begins. This is also done with environment variables:
N:s1,n1,p1:s2,n2,p2:s3,n3,p3: ... :sN,nN,pN
where the components are:
Function | Default | V | R |
---|---|---|---|
calloc(n, 0) | Non-NULL | NULL | No effect |
malloc(0) | Non-NULL | NULL | No effect |
realloc(NULL, 0) | Non-NULL | NULL | No effect |
realloc(non-NULL, 0) | Non-NULL | NULL | NULL |
In all the above cases, if the function returns a non-NULL pointer, it's valid only for a corresponding call to free() or realloc().
For more information, see “Dynamic memory management” in the Heap Analysis: Making Memory Errors a Thing of the Past chapter of the Neutrino Programmer's Guide.
The debug malloc library also uses these environment variables:
In order to revert to the allocator behavior from QNX Neutrino 6.2, do one of the following:
Or:
You can also set both variables to fine-tune the allocator's behavior. The easiest way is to explicitly set the MALLOC_ARENA_CACHE_MAXSZ value to set a cap on the total amount of memory held in the allocator. The MALLOC_ARENA_CACHE_MAXBLK value is more difficult to configure, because arena blocks aren't necessarily the same size, and hence setting the number alone may not give the exact desired behavior.
Safety: | |
---|---|
Cancellation point | No |
Interrupt handler | No |
Signal handler | No |
Thread | Yes |
Don't use brk() and sbrk() with any other memory functions (such as malloc(), mmap(), and free()). The brk() function assumes that the heap is contiguous; in Neutrino, memory is returned to the system by the heap, causing the heap to become sparse. The Neutrino malloc() function is based on mmap(), and not on brk().
In QNX 4, nothing is allocated when you malloc() 0 bytes. Be careful if your code is ported between QNX 4 and QNX Neutrino.
_amblksiz, calloc(), free(), mallopt(), mmap(), realloc(), sbrk()
Heap Analysis: Making Memory Errors a Thing of the Past chapter of the Neutrino Programmer's Guide