Crash due to fr_packet_cmp

[Alan DeKok]

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.