Padam J Singh wrote: > Could this be some sort of a compiler optimization that may be causing > this? May be some memory barrier is required?
I don't see why. All of the lookups, insertions, and deletions into the hash occur in the main processing thread. The child threads process packets through modules, and do *not* touch the hash. I don't see any compiler re-ordering those operations so that they cause problems in one thread of execution. But the fact that the request is still in the hash, AND the packet is free'd is *very* odd. The only calls to "request_free" assert that the request isn't in the hash. The only calls to "rad_free(packet)" are in the function freeing the request, which has the above checks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
