trond-snekvik
commented
7 years ago Hi, sorry for the poor response time.
That's a nice analysis, and a perfectly valid fix to a pretty stupid bug :+1:
I'll push your fix :)
Open twvd opened 7 years ago
trond-snekvik
commented
7 years ago Hi, sorry for the poor response time.
That's a nice analysis, and a perfectly valid fix to a pretty stupid bug :+1:
I'll push your fix :)
Hello,
While stress testing the mesh I've come across a problem where at some point (20 - 30 seconds) mesh nodes would start dropping out and no longer transmitting any data. My data cache size and handle cache size defines are both 8 at the time.
At the time the mesh is stalled, the call to data_entry_allocate() in handle_storage_info_set() was returning DATA_CACHE_ENTRY_INVALID, causing handle_storage_info_set() to return NRF_ERROR_NO_MEM (line 392).
At the time this problem was occuring, my caches looked like this:
As you can see, the data cache is empty and no handle caches are referencing the data cache.
In data_entry_allocate() there is a loop at the top checking for unused data cache entries, but this loop stops after RBC_MESH_DATA_CACHE_ENTRIES because the variable 'allocated' is static and never reset back to 0. So, after the data cache has been filled RBC_MESH_DATA_CACHE_ENTRIES times, it starts looking for unused handle cache entries to free them, but as you can see in my case, the handle cache is unlinked and the data cache is free, so nothing happens and the mesh can no longer send any packets.
My fix for now (which seems to work perfectly) is to change this line in data_entry_allocate from:
for (uint32_t i = allocated; i < RBC_MESH_DATA_CACHE_ENTRIES; ++i)tofor (uint32_t i = 0; i < RBC_MESH_DATA_CACHE_ENTRIES; ++i)disregarding the 'allocated' variable and making use of the initial loop to check for 'free' data cache entries again. The 'allocated' variable seems to be useless, because the data cache already has a way of being marked as 'in use' or 'free'.Please share your opinion on this fix, perhaps I'm missing something.