[Python-Dev] another dict crasher

[Tim Peters]

[Michael Hudson]
> ...
> If noone beats me to it, I'll post a better fix to sf next week,
> complete with test-cases and suitably "encouraging" comments.

Ah, no need -- looks like I was doing that while you were writing this.
Checked in already.  So long as we're happy to settle for senseless results
that simply don't blow up, the only other trick you really needed was to
save away the value in a local vrbl and incref it across the key->string
bit; then you don't have to worry about key->string deleting the value, or
about the table entry it lived in going away (because you get the value from
the (still-incref'ed) *local* vrbl later, not from the table again).

> I can't easily see other examples of the problem; there certainly
> might be things you could do with comparisons that could trigger
> crashes, but that code's so hairy that it's almost impossible for me
> to be sure.

It's easy to be sure:  any code that tries to remember anything about a dict
(ditto any mutable object) across a "dangerous" call, other than the mere
address of the object, is a place you *can* provoke a core dump.  It may not
be easy to provoke, and a given provoking test case may not fail across all
platforms, or even every time you run it on a single platform, but it's "an
obvious" hole all the same.