How to debug a stack overflow error in a nRF5340

[lcj]

I am getting this error on the 7th time I perform an action:

[00:02:31.772,277] <err> lvgl: (151.772, +67506)         lv_mem_realloc: couldn't allocate memory       (in lv_mem.c line #211)
[00:02:31.772,521] <err> lvgl: (151.772, +0)     lv_mem_buf_get: Asserted at expression: buf != NULL (Out of memory, can't allocate a new buffer (increase your LV_MEM_SIZE/heap size))   (in lv_mem.c line #312)

I understand it's an lvgl error and could be specific to lvgl but I think, considering it's only happening on the 7th time I perform an action, that it's a memory problem someplace else. I was thinking being able to print the available RAM would help. Is there a way to do that? Is there a way to see what variables are in RAM?

I'm using Zephyr with the VSC connect add-in.

[Vidar Berg]

Hello,

Please check which memory configs you have for LVGL in your .config file (located in build/zephyr/ for SDK v2.6.x and below, or build/<app name>/zephyr for SDK v2.7.0 and above).

Below are the default configurations I got when I built the LVGL sample in SDK v2.7.0. Here it is using Zephyr heap and 16K. It would be interesting to know if you can run more iterations if you increase the mem pool size in your project configuration.

Best regards,

Vidar

[lcj]

I can. I doubled it and can now run 23.

[Vidar Berg]

It sounds like there is a memory leak. I would expect lv_mem_realloc()/lv_mem_alloc() to be followed by lv_mem_free() at some point. Are you able to debug the project to find out why lv_mem_free() is not called?

[lcj]

I am able to debug the project. Where would I put the break?

[Vidar Berg]

It depends on how you’re using the library in your application. You can start by adding more logging in the lgvl module to track the code flow and find out why the memory is not being freed.

[lcj]

What should I log? Can I log the RAM?

[Vidar Berg]

As you were able to run more iterations by increasing the memory pool it suggests that some objects allocated from heap are not being freed after use with lv_mem_free(). It is possible to monitor the heap usage. However, we already know that the heap is being used up. 

Are you able to reproduce this with the original LVGL sample in the SDK?