How do I set LV_USE_BUILTIN_MALLOC without using lv_conf.h? (platformio+espidf+lvgl)

  1. build configuration : platformio + espidf + lvgl (not used lv_conf.h)
    • included lvgl and lvgl_esp32_driver in espidf project

image

  1. build error occurred!
    image

→ Not defined function lv_malloc_builtin
#define LV_USE_BUILTIN_MALLOC 0 in lv_conf_internal.c
→ deactivated lv_malloc_builtin functions in lv_malloc_builtin.c

image

  1. How do I set the LV_USE_BUILTIN_MALLOC or CONFIG_LV_USE_BUILTIN_MALLOC by menuconfig
    image
    There was no effect even if I didn’t check the first line of the menu below.

  2. CONFIG_item related to memory are as follows. (sdkconfig)

#
# Memory settings
#
# CONFIG_LV_MEM_CUSTOM is not set
CONFIG_LV_MEM_SIZE_KILOBYTES=32
CONFIG_LV_MEM_ADDR=0x0
CONFIG_LV_MEM_BUF_MAX_NUM=16
# CONFIG_LV_MEMCPY_MEMSET_STD is not set
# end of Memory settings

When set in espidf menuconfig, the related variables in the sdkconfig file are updated and affect the variables used in lv_conf_internal.h

But what should I do if the variable set in menuconfig is not used for lv_conf_internal.h?
For example, if the item “Set number of maximally cached circle data” is set to 4 in menucconfig and saved, it is updated to CONFIG_LV_CIRCLE_CACHE_SIZE=4 in the sdkconfig file. However, CONFIG_LV_CIRCLE_CACHE_SIZE is not used for lv_conf_internal.h. What should I do to apply it in this case?

image

Hi,

LV_USE_BUILTIN_MALLOC is a new define in the master branch where we develop v9. So master is not stable at this moment. See the README:

@kisvegabor

Can “LV_USE_BUILTIN_MALLOC” corrupting my memory data ???

I’m not sure if the problem is with the dynamic allocation used by the lib lvgl.

When running this code, my variable, not related to lvgl, is zeroed out.

/* Clear structure and point all empty lists at the null block. */
static void control_constructor(control_t * control)
{
    int i, j;

    control->block_null.next_free = &control->block_null;
    control->block_null.prev_free = &control->block_null;

    control->fl_bitmap = 0;
    for(i = 0; i < FL_INDEX_COUNT; ++i) {
        control->sl_bitmap[i] = 0;
        for(j = 0; j < SL_INDEX_COUNT; ++j) {
            control->blocks[i][j] = &control->block_null;
        }
    }
}
/*Enable and configure the built-in memory manager*/
#define LV_USE_BUILTIN_MALLOC 1
#if LV_USE_BUILTIN_MALLOC
    /*Size of the memory available for `lv_malloc()` in bytes (>= 2kB)*/
    #define LV_MEM_SIZE (128U * 1024U)          /*[bytes]*/

    /*Size of the memory expand for `lv_malloc()` in bytes*/
    #define LV_MEM_POOL_EXPAND_SIZE 0

    /*Set an address for the memory pool instead of allocating it as a normal array. Can be in external SRAM too.*/
    #define LV_MEM_ADR 0     /*0: unused*/
    /*Instead of an address give a memory allocator that will be called to get a memory pool for LVGL. E.g. my_malloc*/
    #if LV_MEM_ADR == 0
        #undef LV_MEM_POOL_INCLUDE
        #undef LV_MEM_POOL_ALLOC
    #endif
#endif  /*LV_USE_BUILTIN_MALLOC*/
/***************************
 * CURRENT VERSION OF LVGL
 ***************************/
#define LVGL_VERSION_MAJOR 9
#define LVGL_VERSION_MINOR 0
#define LVGL_VERSION_PATCH 0
#define LVGL_VERSION_INFO "dev"

@kisvegabor

I am wondering if the same issue was coming up for me with the CPython Binding. I had to remove the use of all of the builtins and instead use malloc and all of the rest of the memory type functions from the standard c library. If memory serves I remember seeing things zeroed out, or I would get an access violation error. My issues were with bits tied to LVGL so there is a difference but maybe the problems are linked in some manner.

Can you reproduce it on PC? If you so enabling ASAN could help a lot to find these kind of memory errors.

I’m pretty sure that the built in malloc it working fine, it’s rather an out-of-bounds write somewhere.

You can also enable all LV_USE_ASSERT_...s.

@kisvegabor,

I disabled the instruction and data caches from my processor and my variable is not corrupted anymore.

It is only a double variable.

Complicated.