This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: couple of new list.sort bugs
Type: Stage:
Components: Interpreter Core Versions: Python 2.4
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: mwh Nosy List: mwh, rhettinger
Priority: normal Keywords:

Created on 2003-11-25 11:12 by mwh, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
list-nagery.diff mwh, 2003-12-01 18:36 fix attempt #1
list-nagery-2.diff mwh, 2003-12-02 12:13 fix attempt #2
Messages (9)
msg19115 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-11-25 11:12
I really feel I should apologise for this one:

[mwh@pc150 build-debug]$ cat t.py
class SortKiller(object):
    def __init__(self, i):
        pass
    def __del__(self):
        del l[:]
 
l = range(10)
l.sort(key=SortKiller)
[mwh@pc150 build-debug]$ ./python t.py
Segmentation fault

This can be fixed by moving the "restoring the objects
of the list from the wrappers" code *before* the "put
saved_ob_item back in the list" code.

The second is less serious but probably more annoying
to fix:

[mwh@pc150 build-debug]$ cat u.py
def k(x): return 1/x
 
l = range(-2,2)
try:
   l.sort(key=k)
except ZeroDivisionError:
   pass
print l
[mwh@pc150 build-debug]$ ./python u.py
[<sortwrapper object at 0x40130410>, <sortwrapper
object at 0x401303c0>, 0, 1]
[6571 refs]
msg19116 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-11-29 01:56
Logged In: YES 
user_id=80475

The second was easy to fix.  

The first is defying my attempts to fix it.  You're welcome
to take a crack at it.

msg19117 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-12-01 12:37
Logged In: YES 
user_id=6656

I have a feeling that your fix for problem #2 has made
problem #1 harder to fix...

will have a look later, no time right now.
msg19118 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-12-01 17:38
Logged In: YES 
user_id=6656

Here's a much less devious test case:

$ cat w.py
def k(x):
    del l[:]
    return x
 
l = range(10)
l.sort(key=k)
$ ./python w.py
Segmentation fault

i think doing the "hide ob_item" swizzle should be just
about the first thing list_sort does and undoing it should
be about the last.  Patch soon (I hope).
msg19119 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-12-01 18:36
Logged In: YES 
user_id=6656

Boy is this stuff hard to get right!

See what you think of the attached patch.
msg19120 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-12-02 06:52
Logged In: YES 
user_id=80475

On the code path leading to a dsu_fail, does PyMem_FREE()
ever get called?

Would there be some added protection value to INCREFing self
at the beginning and DECREFing it at the end?

msg19121 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-12-02 12:13
Logged In: YES 
user_id=6656

> On the code path leading to a dsu_fail, does 
> PyMem_FREE() ever get called?

Good catch.  New patch attached.

> Would there be some added protection value to INCREFing self
> at the beginning and DECREFing it at the end?

Um, I don't think so, as the calling machinery holds a
reference to self (and all the other arguments) during the
call.  Or did you mean something else?
msg19122 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-12-04 00:57
Logged In: YES 
user_id=80475

Looks good.
Please add your crashers to the test suite and check it all in.
msg19123 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-12-04 11:26
Logged In: YES 
user_id=6656

OK, checked in as:

Objects/listobject.c revision 2.167
Lib/test/test_sort.py revision 1.9
History
Date User Action Args
2022-04-11 14:56:01adminsetgithub: 39596
2003-11-25 11:12:33mwhcreate