using clht while meet some memory problem

[xzwj1699]

hello, I've meet some problem while using clht

at first, I chose the clht_lb_res in my application, and then I got a core dump caused by ht_resize().

then I changed to clht_lb, and init the hashtable like clht_create(5000), and then I got a checksum mismatch(this comes from an asseet in my own application ), so I print all the item in the hashtable(I used it like int --> char*).

and the problem is the char* is all right, but the content char* point to is changed.

I'am sure that it's clht's problem because after I changed the hashtable to SPTAG(another hashtable implementation), the problem disappeared

so i guess that there may be some hidden bugs in the ssmem part of your program。it maybe implicitly change the contents of the memory, or conflicts with the memory management of my application

[trigonak]

Hello,

Interesting. clht_lb with no resize does not use the ssmem, since there is no need to garbage collect buckets (see https://github.com/LPD-EPFL/CLHT/blob/master/src/clht_lb.c).

Some invariants that CLHT has are:

• Keys are initialized to 0 -- i.e., value 0 means that the bucket is empty (

  CLHT/src/clht_lb.c

  Line 163 in b86ea2c

  hashtable->table[i].key[j] = 0;

  ). The application should not use 0 as valid keys
• A value that is removed should not be put again with the same key. This is because CLHT implements a simple snapshot algorithm (

  CLHT/src/clht_lb.c

  Line 196 in b86ea2c

  clht_val_t val = bucket->val[j];

  ). So, if your application is removing and releasing some char * memory and then allocates possibly the same memory and add its back, this can cause correctness issues.

Otherwise, I do no see how CLHT could rewrite the pointed by the char * memory. For CHLT, these are "just" values and w/o resizing, they are never copied or migrated.