Hello Benoit,


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?








From: ocr-dev-bounces@lists.01.org [mailto:ocr-dev-bounces@lists.01.org] On Behalf Of Benoit Meister
Sent: Monday, April 15, 2013 2:07 PM
To: Technical discussion about OCR
Subject: [OCR-dev] Is the tlsf allocator used by default ?



I'm systematically using NO_ALLOC in my calls to ocrDbCreate, but in a case when I try to allocate a small block (16 bytes), it seems that tlsf-allocator is used.

I was expecting malloc to be used instead.

My understanding is that when using custom allocators, one has to deal with the fact that the allocators use a part of the allocated space. This probably rules out allocating a really small buffer like this one. So I don't want to use any custom allocator (at the moment).

Valgrind tells me this:


==8485== Invalid write of size 4
==8485==    at 0x4047FA9: removeFreeBlock (tlsf-allocator.c:408)
==8485==    by 0x404845C: tlsf_malloc (tlsf-allocator.c:881)
==8485==    by 0x4048599: tlsfAllocate (tlsf-allocator.c:1011)
==8485==    by 0x4048C81: regularCreate (regular.c:48)
==8485==    by 0x4047B5E: ocrDbCreate (ocr-db.c:67)

tlsf-allocator.c:408 is this line (I have printfs here and there so the line # may be off):

    ST_SIZE(ADDR_OF(header_t, GET_ADDRESS(second), prevFreeBlock), first.value);


- Benoit