[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: > Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python > 2.7. Why not adding these new tests to Python 2.7? The tests don't crash Python 2.7. So they are not useful as a test whether the bug has been worked-around. I actually don't know how to te

[issue8847] crash appending list and namedtuple

STINNER Victor added the comment: > Please rephrase your question: what tests did I not add? > I did add the tests that Stefan proposed. Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python 2.7. Why not adding these new tests to Python 2.7? -- ___

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: > You didn't add any test for non regression?? Please rephrase your question: what tests did I not add? I did add the tests that Stefan proposed. -- ___ Python tracker ___

[issue8847] crash appending list and namedtuple

STINNER Victor added the comment: You didn't add any test for non regression?? -- ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: Thanks for the research and the fix! -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue8847] crash appending list and namedtuple

Roundup Robot added the comment: New changeset 2638ce032151 by Martin v. Löwis in branch '3.2': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/2638ce032151 New changeset 029cde4e58c5 by Martin v. Löwis in branch 'default': Issue #8847: Disable COMDAT

[issue8847] crash appending list and namedtuple

Roundup Robot added the comment: New changeset 5a8c5631463f by Martin v. Löwis in branch '2.7': Issue #8847: Disable COMDAT folding in Windows PGO builds. http://hg.python.org/cpython/rev/5a8c5631463f -- nosy: +python-dev ___ Python tracker

[issue8847] crash appending list and namedtuple

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: > If anyone can confirm that this is the case or has a pointer to > the relevant vcproj docs, I'd be thrilled. http://msdn.microsoft.com/de-de/library/microsoft.visualstudio.vcprojectengine.vclinkertool.enablecomdatfolding(v=vs.90).aspx http://msdn.microsoft.c

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: > Also, the only person to run the tests with the PGO build will probably > be Martin just before the releases. :) We could set up a buildbot slave which does PGO builds, provided somebody volunteered an installation (including VS Pro), and somebody contributed

[issue8847] crash appending list and namedtuple

Changes by Stefan Krah : Added file: http://bugs.python.org/file26634/issue8847-3.3.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue8847] crash appending list and namedtuple

Changes by Stefan Krah : Removed file: http://bugs.python.org/file26632/issue8847-3.3.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8847] crash appending list and namedtuple

Changes by Stefan Krah : Added file: http://bugs.python.org/file26633/issue8847-3.2.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue8847] crash appending list and namedtuple

Stefan Krah added the comment: New patches with tests for 3.2 and 3.3. For 3.2 I determined empirically that EnableCOMDATFolding="1" (and not "0") turns on NOICF. If anyone can confirm that this is the case or has a pointer to the relevant vcproj docs, I'd be thrilled. -- Added file: ht

[issue8847] crash appending list and namedtuple

Antoine Pitrou added the comment: > Antoine Pitrou wrote: > > I think we want to add those tests to the test suite as well. > > What's a good place? Shall we just add one of the tests to test_tuple? Sounds good. And another of them to test_list perhaps as well :) > Also, the only person to ru

[issue8847] crash appending list and namedtuple

Stefan Krah added the comment: Antoine Pitrou wrote: > I think we want to add those tests to the test suite as well. What's a good place? Shall we just add one of the tests to test_tuple? Also, the only person to run the tests with the PGO build will probably be Martin just before the releases

[issue8847] crash appending list and namedtuple

Antoine Pitrou added the comment: > Here's a patch based on the analysis. All test cases given here > now raise TypeError. I think we want to add those tests to the test suite as well. -- ___ Python tracker ___

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: I presume the previously crashing test cases should be added to the test suite, to detect reversion. Is there a method (faulthandler?) to keep tests going, or stop gracefully, when adding a once-crasher that could revert? -- __

[issue8847] crash appending list and namedtuple

Stefan Krah added the comment: Here's a patch based on the analysis. All test cases given here now raise TypeError. -- keywords: +patch Added file: http://bugs.python.org/file26623/issue8847.diff ___ Python tracker

[issue8847] crash appending list and namedtuple

Stefan Krah added the comment: Martin v. L??wis wrote: > > If not, then I doubt PGO is buying us anything anyway. > > It was originally added because people reported measurable speedups when > profile-guided optimization is used, for VS 2008. For libmpdec/64-bit I've measured huge speedups in

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: > Do we even use PGO to the fullest extent? Does someone actually build an > instrumented Python, run training inputs on it, and then rebuild with the > training data to take advantage of the profile-guided optimizations? Yes, I do, on every release of Python.

[issue8847] crash appending list and namedtuple

STINNER Victor added the comment: > I noticed when building with VC++ 2010 Express on the PGI/PGO > builds that it warns about PGO not being available. Even if PGO is not available, wrap_binaryfunc() and wrap_binaryfunc_l() functions get the same address when Python is compiled in "PGUpdate" mo

[issue8847] crash appending list and namedtuple

Meador Inge added the comment: > This is probably meant to imply that pointers to different functions must > not compare equal. I think so. Also, in our case the functions have different names, therefore they can't be the "same" function. > So if this is determined to be a compiler bug, the mo

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: OTOH, 6.5.9p6 says "Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function [...]" This is probably meant to imply that pointers to

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: > Having the compiler merge different pointers just because the functions > happen to have the same implementation is simply *not cool* from the > point of view of the CPython code base. I believe the compiler is completely entitled to do so according to the

[issue8847] crash appending list and namedtuple

Meador Inge added the comment: Nice work Victor. > Can we turn that particular optimisation off? /OPT:NOICF is probably what we are looking for [1]: """ /OPT:ICF can result in the same address being assigned to different functions or read only data members (const variables compiled with /Gy).

[issue8847] crash appending list and namedtuple

Nick Coghlan added the comment: Nice detective work, Victor. Can we turn that particular optimisation off? We use function addresses for identification purposes in many more places than just this one. Having the compiler merge different pointers just because the functions happen to have the s

[issue8847] crash appending list and namedtuple

STINNER Victor added the comment: When Python is compiled by Visual Studio 10 in PGUpdate mode, duplicated functions are merged to become the same unique function. The C code of wrap_binaryfunc() and wrap_binaryfunc_l() functions is the same and so both functions get the same address. For "cl

[issue8847] crash appending list and namedtuple

Stefan Krah added the comment: I can reproduce this exclusively with the pgupdate build: msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=win32 msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=win32 PCbuild\Win32-pgo\python.exe Python 3.3.0b1 (default, Jul

[issue8847] crash appending list and namedtuple

Changes by Alex Gaynor : -- nosy: +alex ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue8847] crash appending list and namedtuple

Changes by Terry J. Reedy : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue8847] crash appending list and namedtuple

Georg Brandl added the comment: Raising priority. This should be investigated properly before 3.3 final. -- nosy: +georg.brandl priority: high -> deferred blocker ___ Python tracker

[issue8847] crash appending list and namedtuple

Antoine Pitrou added the comment: The exact same issue happens when concatenating a list subclass to a tuple: >>> () + L([1,2]) [1, 2] >>> (3,) + L([1,2]) # crash Also, note that in this case a list is returned, not a tuple despite the first operand being a tuple. Conversely: >>> [] + T((1,2)

[issue8847] crash appending list and namedtuple

Antoine Pitrou added the comment: For some reasons I was able to reproduce under 64-bit Windows with the 3.3b1 official build, but neither with my own VS9.0-compiled build, nor with the 3.2 official build. To reproduce: >>> class T(tuple): pass ... >>> t = T((1,2)) >>> [] + t (1, 2) >>> [3,]

[issue8847] crash appending list and namedtuple

Changes by Atsuo Ishimoto : -- nosy: +ishimoto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue8847] crash appending list and namedtuple

Changes by Terry J. Reedy : -- versions: -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue8847] crash appending list and namedtuple

Changes by Éric Araujo : -- nosy: +rhettinger versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue8847] crash appending list and namedtuple

benrg added the comment: The bug is still present in 3.2. -- versions: +Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue8847] crash appending list and namedtuple

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue8847] crash appending list and namedtuple

Matthew Barnett added the comment: I've just found that: [1] + foo() crashes, but: [1].__add__(foo()) gives: Traceback (most recent call last): File "", line 1, in [1].__add__(foo()) TypeError: can only concatenate list (not "foo") to list (IDLE on Windows XP

[issue8847] crash appending list and namedtuple

Martin v. Löwis added the comment: The binaries get compiled with the PGInstrument/PGUpdate configurations. -- ___ Python tracker ___

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: Good try, but for one run, the ids of foo, x, a, and b are >>> 15719440 15717880 15273104 12266976 -- ___ Python tracker ___ __

[issue8847] crash appending list and namedtuple

Jack Diederich added the comment: if the id() of the left operand is identical to the id() of the first element in the result it would strongly support compiler skulldugerry. class Crasher(tuple): pass foo = Crasher() x = [1] a = x + foo b=a[0] if id(b) == id(x): raise Exception("It's the C

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: 1) answered before you asked (yes, similar) 2) (same thought) I am using PSF windows installer, however that was prepared. Martin? -- nosy: +loewis ___ Python tracker

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: "can't reproduce" does not inform as to what *did* happen with which code. More experiments: foo = str() TypeError: can only concatenate list (not "str") to list class s(str): pass foo = s() TypeError: Can't convert 'list' object to str implicitly Why is it t

[issue8847] crash appending list and namedtuple

Jack Diederich added the comment: Two more probes: 1) does it also have the same strange/crashy behavior when you subclass list and concat that to a tuple? 2) does dropping the optimization level down to -O help? This has "compiler quirk" written all over it. The C-code for list and tuple

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: Substituting foo = tuple() TypeError: can only concatenate list (not "tuple") to list class Crasher(tuple): pass foo = Crasher() a = [1] + foo b=a[0] print (type(a), len(a), type(b), len(type(b)), type(type(b))) 1 [] 1 as before, so namedtuple is not, in pa

[issue8847] crash appending list and namedtuple

Jack Diederich added the comment: I can't reproduce on 3k trunk with Ubuntu 10.04, gcc 4.4.3 namedtuples are just a subclass of tuple with only two dunder methods defined (a plain __new__ with empty __slots__). Can you provoke the same behavior with plain tuples, or a subclass of tuple that

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: More experiments from collections import namedtuple foo = namedtuple('foo', '') a = [] + foo() print (a, type(a), len(a)) # () 0 ie, a standard empty tuple, whereas a = [1,1] + foo() crashes immediately. So the behavior of list()+namedtuple depends on the len

[issue8847] crash appending list and namedtuple

Changes by Raymond Hettinger : -- priority: normal -> high ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue8847] crash appending list and namedtuple

Changes by Jack Diederich : -- nosy: +jackdied ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue8847] crash appending list and namedtuple

Terry J. Reedy added the comment: Running the exact same binary on winxp with an amd athlon processor, I *did* get a crash after about 5 seconds. "python.exe has encountered a problem and needs to close. We are sorry for the inconvenience." Trying again with IDLE instead of the command window,

[issue8847] crash appending list and namedtuple

R. David Murray added the comment: I can't reproduce this on either 3.1.2 or py3k trunk. -- nosy: +r.david.murray resolution: -> works for me ___ Python tracker ___

[issue8847] crash appending list and namedtuple

New submission from benrg : c:\>python Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from collections import namedtuple >>> foo = namedtuple('foo', '') >>> [1] + foo() At