Re: Crash due to fr_packet_cmp

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.