[Python-Dev] segfaults due to hash randomization in C OrderedDict (original) (raw)

MRAB python at mrabarnett.plus.com
Fri May 22 01:55:55 CEST 2015

On 2015-05-22 00:22, Eric Snow wrote:

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 testbasic >> testconfigparser >> >> Some seeds always segfault and some seeds never segfault. >> > OK, another thought. > > In "odictgetindex" 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 PyObjectHash call. Also, there's no check for a changed hash. The code compares the size of makeys (effectively the dict keys hash table) against the size of of the odict "fast nodes" table. Ah, OK.

I'm not looking at the use of "PyTuple_Pack". As I understand it, "PyTuple_Pack" borrows the references of the objects passed, and when the tuple itself is DECREFed, those objects will be DECREFed

"odict_reduce" calls "PyTuple_Pack", passing 1 or 2 references to Py_None which aren't INCREFed first, so could there be a bug there? (There might be similar issues in other functions.)

More information about the Python-Dev mailing list