Dnia 2014-08-28, czw o godzinie 17:51 +0000, Shawn Debnath pisze: > The problem is that it breaks scenarios where the user may > use a temp buffer to build the key, then insert or put it in the xhash > and then free the buffer memory.
This is invalid use of xhash. > Assumption here is that xhash code > would allocate necessary buffer to store internal data and not rely on > user supplied memory to maintain it=A9=F6s internal data structures. There is no such assumption. It's a gotcha waiting for every new jabberd2 dev. ;-) > Any ideas if there was a particular reason this was designed this way? I > imagine, in most of the cases the key is inside the object being stored > so it works out. This is for efficiency reasons. Strings in jabberd are usually coming from incoming NADs (notice xhash_putx() taking the len of the key) or being allocated in memory pools associated with objects. It would be a waste of memory and CPU to make a copy each time an object gets stored in hash or removed from hash. Also, when these strings are part of the object they identify, memory management is as easy as freeing the object and it's associated memory pool (assuming it was already removed from all its references including xhashes). > However, as you can see, the xhash implementation > can¹t be fully exploited/used. The fact you are allocating object identifier strings on stack/heap is a sign of bad design. Could you rethink your design to include the identifier as a part of the object it names?
