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.

Author steve.dower
Recipients brian.curtin, loewis, nadeem.vawda, skrah, steve.dower, vstinner
Date 2014-06-19.15:14:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I'd be fine to reconsider if a previously-demonstrated bug is now 
> demonstrated-fixed. However, if the actual bug persists, optimization 
> should be disabled for all code, not just for the code that allows to 
> demonstrate the bug. 

I'm okay with that. I thought you meant never enable optimizations with that compiler ever again, which is obviously ridiculous and I should have dismissed the idea on that basis rather than posting a snarky response. Sorry.

> It seems to me that at the time the wrong branch is taken, f->id
> could be in the registers in the wrong order (same as in msg170985),
> but when the error message is printed, the value is read from
> memory.  This is just a guess of course.

I checked that and the registers are fine. Here's the snippet of disassembly I posted with the bug I filed:

 mov     edx,dword ptr [edi+4]  ; == 0x40000000
 mov     ecx,dword ptr [edi]    ; == 0x00000001
 test    edx,edx           ; should be cmp edx,40000000h or equiv.
 ja      lbl1  ; 'default:'
 jb      lbl2              ; should be je after change above
 cmp     ecx,21h
 jbe     lbl2              ; should probably be lbl3
 ; default:
 cmp     ecx,1
 jne     lbl3
 ; case 0x4000000000000001

It's clearly an incorrect `test` opcode, and I'd expect switch statements where the first case is a 64-bit integer larger than 2**32 to be rare - I've certainly never encountered one before - which is why such a bug could go undiscovered.

When I looked at the disassembly for memoryview it was fine. I actually spent far longer than I should have trying to find the bug that was no longer there...

Also bear in mind that I'm working with VC14 and not VC10, so the difference is due to the compiler and not simply time or magic :)
Date User Action Args
2014-06-19 15:14:59steve.dowersetrecipients: + steve.dower, loewis, vstinner, nadeem.vawda, brian.curtin, skrah
2014-06-19 15:14:59steve.dowersetmessageid: <>
2014-06-19 15:14:59steve.dowerlinkissue15993 messages
2014-06-19 15:14:58steve.dowercreate