Your patch does not fix the problem.
It will make the first X hashtable grow operations random.
But the moment you already inserte 65536 entries the HashTable is now big enough
to launch the attack.
Maybe your test script already breaks your patch the moment you try to insert
2^17 entries.
Otherwise the attack script might need some tweaking. Anyway, your patch will
not solve the problem.

You are mistaken to believe that randomizing the TableSize will stop predictable
collisions: This is only true if you try to exploit the problem with numerical
indicies.
The moment you use alpha numerical keys and produce collisions in the DJB
hashing function the table size does not matter anymore, because the return
value of the hash function is the same.

<laruence> I got you point, and agree in theory, yes, the string hash value could
be the same, does anyone have a method to compute it in real?
<nikic> yes
<laruence> I really doubt that if we can find so many string keys with the same
hash value to be able launch a attach, and won't reach the max post size

sesser, I am not good at algorithm, so if you can help me, I will appreciate.
just a guess, what about change the zend_hash_func, add some new seed like:
register ulong hash = 5381 + nKeyLength;
thanks

laruence: nothing against you, but fixing the hash table thing is not a simple
easy fix. It must be done by someone who understands the mathematical problem of
hash collisions and who understands the impact of making changes to a hash
function.
Just changing some constants in the algorithm will not improve the situation.
The opposite can be the case. By changing some constants it could be possible to
destroy the distribution of collisions and suddenly some values collide more
often than others.
So please do not try to fix a problem that must be solved by someone with the
mathematical background knowledge.