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

[MRAB]

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 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.
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.)