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 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?

[lcj]

I am not able to replicate it with the sample. I started with the sample, but it didn't have all the capabilities I needed for the overall app. Could the heap be used up by a different process or is it likely to be lvgl? When I change the CONFIG_LV_Z_MEM_POOL_SIZE from 16384 to 32768 it happens around the 23rd time vs 8th time. Does that help isolate the problem?

[Vidar Berg]

The heap allocated by CONFIG_LV_Z_MEM_POOL_SIZE is reserved to the lvgl, and is not used by other modules. Since you are not seeing this with the sample code, I think it makes sense to review how you are using the library in your application.  

Here is an example I found where incorrect API usage led to a memory leak: https://github.com/lvgl/lvgl/issues/2240 

[lcj]

Thank you. I will review the sample in the link you provided. I used the sample code to get started but in real world applications the usage of lvgl is likely to be different. For example, they don't show how to switch screens in the example, but that is a common use case. Additionally, they don't show how to display images from files in the sample, but it is a feature of lvgl. I think what I am looking to understand is how to debug the issue when it happens. My initial thought was printing the RAM to narrow down where it might be happening. I could use Nordic debugging tools but don't have the RAM tab for some reason. Is there something you would do at this point given that the code has evolved far beyond the sample?