Bug #83916 for mod_perl: test update for perl 5.16.3

Steve Hay via RT wrote: Show quoted text
I can reproduce the failure with a Debian stable perl 5.10.1. The problem is that 5.10.1's hash logic won't perform a split as a result of an insertion that used a new bucket. Because your version of the attack pads using arbitrary keys, and because the prior part of the attack has concentrated keys in one bucket, it's especially likely that any particular padding key will hit a previously-unused bucket. As you pad to the power of two plus one (not just to the power of two as the debug message claims), you have two padding insertions that have the chance to trigger a split. Depending on the keys already in the stash, there's a substantial chance that they'll both get fresh buckets and so fail to trigger a split. You can see this happen if you extend the "debug sprintf ..." trace output into the padding loop. My patch avoids this failure in two ways, one of them intentional. The intentional one is that, rather than assuming that the split will occur at a particular number of keys, it looks at the number of buckets in use and keeps padding until it observes that a split has actually occurred. I wasn't thinking about 5.10; this logic just avoids that entire class of failure modes based on faulty understanding of the core's splitting logic. The accidental aspect is that, because my patch continues the hash collision attack rather than using arbitrary keys, the padding never hits a fresh bucket, and so on 5.10 is always eligible to cause a split. The necessary ingredients for a better patch are the larger $bits from your patch and the bucket-count logic from my patch. Once you're looking at the bucket count, it's insignificant whether the padding keys are part of the hash collision; my patch was overkill in that respect. Attached are a revised patch and the test program that I used in investigating the issue. -zefram