[Python-Dev] segfaults due to hash randomization in C OrderedDict
Eric Snow
ericsnowcurrently at gmail.com
Fri May 22 01:22:58 CEST 2015
More information about the Python-Dev mailing list
Fri May 22 01:22:58 CEST 2015
- Previous message (by thread): [Python-Dev] segfaults due to hash randomization in C OrderedDict
- Next message (by thread): [Python-Dev] segfaults due to hash randomization in C OrderedDict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] segfaults due to hash randomization in C OrderedDict
- Next message (by thread): [Python-Dev] segfaults due to hash randomization in C OrderedDict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list