You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
where, even though we are freeing up the memory pointed by redisClusterNode* or dictEntry, we are not unlinking it from the table. Hence it gets looked up later on(during selectNode()), which would be a dangling pointer.
if ((he = ht->table[i]) == NULL)
continue;
while (he) {
nextHe = he->next;
dictFreeEntryKey(ht, he);
dictFreeEntryVal(ht, he); // memory released, but entry not set to NULL, so ht->table[]->val holds a dangling pointer ?
hi_free(he); // memory released, but entry not set to NULL, so ht->table[] holds a dangling pointer ?
ht->used--;
he = nextHe;
}
And also, other thing that looks odd is the library trying to reattempt discovery when the redisClusterAsyncContext object is getting deleted. Maybe we should prevent that path altogether, in case of redisClusterAsyncFree() where it's about to tear everything down anyways.
Posting some more thoughts, selectNode() is trying to do a dictNext(). So, if we don't set the he object to NULL once we free it inside _dictClear(), any later dictNext() access might still think the entry as valid and try to process that (i.e when the execution is still inside _dictClear()).
Hi, came across this crash during one of the runs.
Looks like the execution was at this line number when the crash happened
hiredis-cluster/hircluster.c
Line 3878 in a2f1b82
I am suspecting the reason for SEGV could be the below code area:
hiredis-cluster/dict.c
Line 179 in a2f1b82
where, even though we are freeing up the memory pointed by
redisClusterNode*
ordictEntry
, we are not unlinking it from the table. Hence it gets looked up later on(duringselectNode()
), which would be a dangling pointer.And also, other thing that looks odd is the library trying to reattempt discovery when the
redisClusterAsyncContext
object is getting deleted. Maybe we should prevent that path altogether, in case ofredisClusterAsyncFree()
where it's about to tear everything down anyways.cc: @bjosv
The text was updated successfully, but these errors were encountered: