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.)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4