I have particular notes on routines akin to C language malloc(), free() and circular buffer handling functions. Calls to malloc() function in firmware level code is usually quite safe because several malloc() implementations that I read, implements a sort of rudimentary exception handling which would bail out one module execution if not enough space is found when code in the "requesting" module asks for heap memory. However, there are still lingering possible of error when the module lost a reference to allocated memory due to pointer reassignment. I have yet to see bad behaving code like this. But it seems, the assumption on the malloc() implementation is that these things never happened!
As for circular buffers, this kind of thing is in use mostly to talk to storage devices and other "block" devices which transfers quite large amount of bytes in "block"s. Circular buffer implementations could use contiguous memory space if the code that initialize it found one such an available area. However, it could also be implemented as circular linked-list of fragmented chunks which are not necessarily adjacent in the physical memory. This is where things get interesting. A logic bug in function calling the one of the circular buffer function could result to access in the wrong physical memory address. That could happen if a calling function assumes that the circular buffer is implemented as contiguous physical memory chunks instead of a linked memory chunks (not necessarily contiguous in physical memory addresses). In this case, the developer who code the function calling the circular buffer implementation should be blamed as he/she didn't foresee an impending chaos he/she created. Unfortunately, I have yet to see "exception handling" on firmware-level code dealing with such things.
Post a Comment
No comments:
Post a Comment