fr_packet_cmp again

[Alan DeKok]

Josip Almasi wrote:
> compiled current 2.1.11 branch on RHEL 6.0 and RHEL 5.5, hit it with
> about 7.5K req/s, and it dies on both, after about 1-3.5M requests.

  Argh.  I've tested it with 40K packets/s for *days*, and haven't seen
this.

> It's not about threads; tried with -s, and it still dies.

  That's good to know.  I'm not sure what it means, but it's good to know.

> So it seems something still frees data before yanking list...?
> Well, beats me.
> Any hints?

  Grab the "master" branch.  See http://git.freeradius.org for
instructions.  The internal state machine has been *completely*
re-written so that it's sane.  If the bug still exists there, I'll be
shocked.

> Now, how to reproduce:
> 
> - get spizd 0.5 from http://sourceforge.net/projects/spizd/files/
> - unzip, have java in path
> - edit etc/dictionary.txt, enter at least one username:password pair
> - run bin/spizd-radius.sh <server>, verify you get Access-Accept

  Why?  Why not just run "radclient"?  Or radperf (http://networkradius.com)

> - edit etc/spizd.properties: change verboseThis and verboseThat to
> false, change spizd.circular to true
> - run spizd-radius.sh again and wait, it dies about 10-15 mins later
> - optionally, increase maxThreads to kill it faster
> 
> What this test does: Access-Request, Acct Start, (optionally a number of
> Interim-Update), Acct Stop - sending request imediatelly after response
> to previous request is received, thread per session.

  Hmm... that sounds to me like the issue is accounting packets getting
deleted while they're still being referenced.

  Alan DeKok.