Details
-
Bug
-
Resolution: Fixed
-
Major
-
5.0.0
-
Untriaged
-
Release Note
-
Unknown
Description
If a deleted document has its metadata restored back into the HashTable (for example via GET_META), and then the whole value is restored back (for example GET triggering a bgFetch), then the numNonResident count is incorrectly decremented, and can underflow.
In more detail:
- GET_META("deleted_key") -> should result in HashTable state of:
HashTable[0x104e0d818] with numInMemory:0 numDeleted:0 numNonResident:0 numTemp:1 values:
SV @0x104ee0740 X.. ..N. temp: D seq:-3 rev:2 key:"ns:0 key_1" exp:1505929057 vallen:0
- GET("deleted_key") -> should then result in HashTable with numNonResident==0:
HashTable[0x104e0d818] with numInMemory:0 numDeleted:0 numNonResident:0 numTemp:1 values:
SV @0x104ee0740 X.. WDNR temp: seq:3 rev:3501 key:"ns:0 key_1" exp:4277009102 vallen:45 val:"'#_sync{"cas":"0xdeadbeefcafefeed <cut>"
- However we actually end up with a huge negative value:
HashTable[0x104e0d818] with numInMemory:0 numDeleted:0 numNonResident:18446744073709551615 numTemp:1 values:
SV @0x104ee0740 X.. WDNR temp: seq:3 rev:3501 key:"ns:0 key_1" exp:4277009102 vallen:45 val:"'#_sync{"cas":"0xdeadbeefcafefeed <cut>"