The error in the tlsf-allocator will need to be investigated (what does the ‘invalid write of size 4’ mean, more details if you have them. Is it detecting a problem because it allocated a much larger chunk).
That point aside though, I think you are confusing the allocator argument passed to ocrDbCreate and the allocator for the data-blocks. There are actually two levels of allocators:
- the allocator that allocates the data-blocks
- the allocator *inside* each data-block (to use a data-block like a heap).
The former is currently always the TLSF allocator which, I am the first to say, is entirely not adapted to its current use. It was designed to allocate memory in very small spaces (small scratchpads) when only one “agent” is responsible for allocation (for example, an XE would manage its own scratchpad). We definitely need better allocators.
The latter is not really implemented at this point and is controlled by the argument in ocrDbCreate. Currently, that parameter is ignored but the idea is to allow the programmer to specify an allocator for *within* the data-block (one could imagine reusing the TLSF allocator there too, much more appropriate or designing your own).
So, in short:
- could you send me the test case that shows the valgrind error. I thought I had tested this allocator enough but obviously not well enough J.
- does the NO_ALLOC parameter make a bit more sense?
OCR-dev mailing list