RetroSearch Browse

Fri May 22 01:22:58 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-May/140080.html

On Thu, May 21, 2015 at 4:41 PM, MRAB <python at mrabarnett.plus.com> wrote:
> On 2015-05-21 23:17, Eric Snow wrote:
>> The segfault is consistent if I use the same seed (e.g. 7):
>>
>>   PYTHONHASHSEED=7 ./python -m test.regrtest -m test_basic
>> test_configparser
>>
>> Some seeds always segfault and some seeds never segfault.
>>
> OK, another thought.
>
> In "_odict_get_index" again, you say that if the hash has changed, the dict
> might've
> been resized, but could the dict be resized _without_ the hash changing?
>
> Could the value of "keys" still become invalid even if the hash is the same?

Good question.  The only way I can see here that the dict would resize
is during re-entrance to the interpreter eval loop via Python code
potentially triggered through the PyObject_Hash call.

Also, there's no check for a changed hash.  The code compares the size
of ma_keys (effectively the dict keys hash table) against the size of
of the odict "fast nodes" table.

-eric

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-May/140080.html below:

[Python-Dev] segfaults due to hash randomization in C OrderedDict