RE: hash_string broken

> 7482 appears to be the correct one.

In fact it is.

> > There is a possibility that bucket 7482 is the correct one,
> and we're
> > overwriting a correctly inserted key for a different user, multiple
> > times, all coincidentally when the bucket is 6475.
>
> > All our crashes are with this username, which could imply a
> problem with
> > our code related to bucket 7482, but as the auth code
> doesn't see the
> > bucket number, that is rather unlikely.
>
> Or it could be something else stomping on bucket 7482..

Sure. But as to why it does, it's still unknown.

> > On the other hand hash_string behaving non-deterministically is also
> > rather unlikely... any pointers?
>
> One approach is using some smart breakpoints to detect if there is
> memory corruption. At least Intel processors supports hardware data
> watches, not having any impact on the execution until hit.
> watch *(type *)0xADDRESS

I'm using the good old printf, as suggested by Adrian.
Since this is run on a semi-production server (it's the only way to get
the Nxxthousand hits to trigger the bug), having squid crash is more
acceptable than just stopping responding (if squid hangs but is still
bound to the port, PAC-based failover won't work).

-- 
	/kinkie