Re: xhash and it's key
Pull request #79 submitted. https://github.com/jabberd2/jabberd2/pull/79 On 8/28/14, 10:51, "Shawn Debnath" wrote: >Hey there, > >Turns out that when inserting items in xhash, the code stores a pointer to >the key passed in by the user in the xhash node and uses that later to >compare in _get. 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. 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. > >In the example above, the put succeeds, user frees the memory, so its >Pointing to garbage and a later a call to _get can't find the entry >because the keys mismatch, i.e., a user supplied valid string key and >NULL memory that the xhash node points to. > >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. However, as you can see, the xhash implementation >can¹t be fully exploited/used. > >It would be trivial, I would imagine, to make a copy of the key and >store that instead of just the pointer to user supplied memory. On >removal in zap_internal, the memory would be freed. > >Thoughts? Concerns? Let me know :) > >Shawn > > >
jabberd2 web presence
hello, can you recommend plugin for web presence for jabberd2? something like http://www.jabbim.com/services-status-icon.html thank you -- --- Marek Cervenka ===
xhash and it's key
Hey there, Turns out that when inserting items in xhash, the code stores a pointer to the key passed in by the user in the xhash node and uses that later to compare in _get. 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. 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. In the example above, the put succeeds, user frees the memory, so its Pointing to garbage and a later a call to _get can't find the entry because the keys mismatch, i.e., a user supplied valid string key and NULL memory that the xhash node points to. 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. However, as you can see, the xhash implementation can¹t be fully exploited/used. It would be trivial, I would imagine, to make a copy of the key and store that instead of just the pointer to user supplied memory. On removal in zap_internal, the memory would be freed. Thoughts? Concerns? Let me know :) Shawn
