Reallocating create access violation in simulator

Hi

I am using the latest version of LVGL 8.0 with the v8.0 lv_drivers. I am running the simulatoren example code. Running the simulator demoes seems to work fine, but when I’m running my own code(big an to much to share) it half the stoppes in the middle off the execution with a access violation error. Using LVGL log feature I get this:

[Trace] (608477.203, +0)         lv_mem_realloc: allocated at 0x90c700  (in lv_mem.c line #195)
[Trace] (608477.203, +0)         lv_mem_realloc: reallocating 0 with 8 size     (in lv_mem.c line #176)
[Trace] (608477.203, +0)         lv_mem_realloc: allocated at 0x90c730  (in lv_mem.c line #195)
[Trace] (608477.203, +0)         lv_mem_realloc: reallocating 0x90c730 with 16 size     (in lv_mem.c line #176)
End of execution...

Using debug I get a access violation right on the call to realloc at address 0x14. Looking at the line in code just before where it was logged it is though called with 0x90c730 which seem to be a valid address as it was allocated just above.

I’m thinking it could be some task switching going wrong, but don’t know enough about windows systems here to really know.

Any thoughts will be much appreciated.

Found the error, nothing to do with LVGL, but I learned something about heap today.

  uint16_t u16Length = strlen(szName) + 1;
  if (u16Length > EGON_ELEMENT_NAME_MAX_LENGTH)
    u16Length = EGON_ELEMENT_NAME_MAX_LENGTH;
  char_t * name = malloc(u16Length); //TODO use oal
  strncpy(name, szName, u16Length);
  name[u16Length ] = 0;
  psElm->user_data    = name;

thought I was extra carefull using strncpy() and always putting in a 0 at the end, but if you look at the second to last line i should have been:

 name[u16Length - 1] = 0;

That ment that a 0 was written outside of my memory space a apparently it was in the heap mangers space, that was why realloc failed.

Glad that you have found the issue. I suggest using ASAN, it helps a lot to find these issues run time.

1 Like