I am getting confused by this thread (especially the bits about a memory leak) and would like to restate what we think the issues are as a numbered list so can address each. Here is what I think we are discussing,:
- When malloc (or pvPortMalloc()) is called the first time the allocated buffer is cleared to zero, but the second time it is not.
As already mentioned, the standard c library malloc() does not clear allocated memory to zero, if it did it would not be complying with the standard. Also as already mentioned, if you use heap_4 then the heap memory space is a statically allocated array which, also in accordance with the C standard, does get cleared to zero by the C start up code at initialisation time (i.e. before your program executes) . Therefore the first allocation is cleared to zero not because pvPortMalloc() cleared it to zero, but because it was cleared to zero before your application ever executed. All calls to pvPortMalloc() return a buffer that contains whatever the buffer contained before pvPortMalloc() was called.
- How to clear memory to zero.
The standard C library to clear memory to zero is memset(). This is part of C language fundamentals that need to be understood before writing applications in C.
- The contents of memory seems to change between calls to malloc/pvPortMalloc.
If you use the following sequence:
x = pvPortMalloc( 1000 );
vPortFree( x );
y = pvPortMalloc( 1000 );
vPortFree( y );
and it just so happens that x == y (i.e. they point to the same buffer) then the values contained in the buffer pointed to by x and y would normally be expected to be the same because nothing else in that sequence wrote to the buffer pointed to by x/y.
Are you claiming the memory changes even though nothing else is writing to it?
If so, then it is possible in a multithreading system that another task executed and wrote to the memory. Or that your code has a bug and a peripheral interrupt service routine, or DMA, or other peripheral function wrote to the memory.
I don’t understand this point, but when you call malloc()/pvPortMalloc() you receive a buffer that is at least as big as requested using the parameter to the malloc/pvportmalloc call. pvPortMalloc() is a really simple function, so if you step into it you will see that, like all malloc() implementations that follow the C standard, it will align the start address to be correct for the processor, it will allocate a little memory for metadata that enables it to free the memory again, and it will also effectively align the end address to be correct for the processor - so internally and unseen from the application it will actually allocate more than you asked for. On a processor that has 32-bit access requirements it will always align to 4 byte addresses otherwise your the processor will generate an exception with certain types of access.
Any other points in this thread?
If replying, please use the number in the above so I know which part we are talking about…and as per my previous comment understanding the fundamentals of how the language works is really a precondition of writing a USB driver.