[issue13548] Invalid 'line' tracer event on pass within else clause
New submission from Stephan R.A. Deibel : The tracer set with sys.settrace() is called incorrectly with a 'line' event on a 'pass' that is at the end of an 'else' clause on the final line of a function even if the else block is not executed by the interpreter. Whew, talk about an end case! The attached file illustrates this. -- components: Interpreter Core files: badlineevent.py messages: 148974 nosy: sdeibel priority: normal severity: normal status: open title: Invalid 'line' tracer event on pass within else clause type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file23865/badlineevent.py ___ Python tracker <http://bugs.python.org/issue13548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13548] Invalid 'line' tracer event on pass within else clause
Stephan R.A. Deibel added the comment: Sorry, the print statement in the file needs a tweak to work with Python 3.2, but the bug does occur there also. -- ___ Python tracker <http://bugs.python.org/issue13548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13557] exec of list comprehension fails on NameError
New submission from Stephan R.A. Deibel : Calling exec() on code that includes a list comprehension that references a defined local variable x fails incorrectly on "NameError: global name 'x' not defined". -- files: execlistcomp.py messages: 149050 nosy: sdeibel priority: normal severity: normal status: open title: exec of list comprehension fails on NameError type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file23883/execlistcomp.py ___ Python tracker <http://bugs.python.org/issue13557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13557] exec of list comprehension fails on NameError
Stephan R.A. Deibel added the comment: Ah, thanks, there it is... I thought this must be dealt with somewhere but couldn't find it. Maybe should add something to the 'exec' statement docs http://docs.python.org/py3k/library/functions.html#exec to reference this (from a usability-of-docs standpoint). BTW, my code already sends the namespaces to exec (from current stack frame; it's part of a debugger) and probably would break other cases to alter this. Well, anyway, sorry for the invalid bug report... -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue13557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13557] exec of list comprehension fails on NameError
Stephan R.A. Deibel added the comment: Here's a patch to the docs that notes the issue and refers the reader to the relevant execution model docs page. I have also attempted to clarify the "interaction with dynamic features" section of the execution model page. -- keywords: +patch versions: -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file23937/exec-eval-clarification.diff ___ Python tracker <http://bugs.python.org/issue13557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2198] code_hash() can be the same for different code objects
New submission from Stephan R.A. Deibel: The algorithm in code_hash() in codeobject.c can return the same hash value for different code objects. Presumably distinct code objects should be very unlikely to have the same hash value. This bug affected our debugger before we worked around it, and it could affect other things like profilers. Adding the co_filename to the hash would be one way to fix this but I'm not sure if that was purposely avoided in this code? -- components: Interpreter Core files: code_hash_bug.tgz messages: 63083 nosy: sdeibel severity: normal status: open title: code_hash() can be the same for different code objects type: behavior versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5 Added file: http://bugs.python.org/file9565/code_hash_bug.tgz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2198> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2198] code_hash() can be the same for different code objects
Stephan R.A. Deibel added the comment: I should have noted that adding co_firstlineno as well to the hash would be necessary to distinguish like code objects within the same file. The example has them on the same lines in different files but changing the first line of the defs doesn't matter. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2198> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30676] Potential for GIL deadlock on Windows in threadmodule acquire_lock
New submission from Stephan R.A. Deibel: In acquire_timed in _threadmodule.c (used to implement threading lock acquire()) there is an optimization from https://github.com/python/cpython/commit/e75ff35af2b6c85d48c68b95f295aeac7396b162 that says it first tries non-blocking lock w/o releasing the GIL. However, it seems that this call can block on Windows. The call to PyThread_acquire_lock_timed(lock, 0, 0) (w/o releasing GIL) on Windows calls EnterNonRecursiveMutex which in turn, in the _PY_USE_CV_LOCKS impl, immediately calls PyMUTEX_LOCK as if it's not going to block. However, various implementations of this seem like they can block. Specifically, the impls of PyMUTEX_LOCK that end up using AcquireSRWLockExclusive and EnterCriticalSection both block. The only case that is correct (does not block) is when !_PY_USE_CV_LOCKS where EnterNonRecursiveMutex() instead calls WaitForSingleObjectEx() with the zero timeout. This seems like an incorrect potential for GIL deadlock, because the thread blocks without releasing GIL. Shouldn't it ultimately be using TryAcquireSRWLockExclusive and TryEnterCriticalSection in these two cases? This seems like an issue on Windows only. The pthreads implementations look like they correctly handle timeout of 0 sent to PyThread_acquire_lock_timed(). -- components: Library (Lib), Windows messages: 296088 nosy: paul.moore, sdeibel, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Potential for GIL deadlock on Windows in threadmodule acquire_lock type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue30676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30676] [Windows] Potential for GIL deadlock on Windows in threadmodule acquire_lock
Stephan R.A. Deibel added the comment: I think I misunderstood the implementation of EnterNonRecursiveMutex -- the mutex that could block there is the internal 'cs' mutex, which would only be held only briefly while Enter/LeaveNonRecursiveMutex are running, and it looks like the 'cs' mutex is released before doing anything that blocks (in the two impls of PyCOND_WAIT and PyCOND_TIMEDWAIT). So my report is invalid and I'm closing it. Sorry about that! -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue30676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine
New submission from Stephan R.A. Deibel: The changes made in Issue19788 break the ability to build x64 build target on a 32-bit Windows machine because PreBuildEvent entries in pythoncore.vcxproj end up trying to run the 64-bit kill_python.exe, causing critical build steps to fail. Removing those PreBuildEvents by manually editing pythoncore.vcxproj served as a work-around. -- components: Build messages: 211093 nosy: sdeibel priority: normal severity: normal status: open title: Always running kill_python breaks building x64 on 32-bit Windows machine type: compile error versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue20609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine
Stephan R.A. Deibel added the comment: There's no patch attached... or am I just confused? -- ___ Python tracker <http://bugs.python.org/issue20609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine
Stephan R.A. Deibel added the comment: Yes, thanks, that patch fixes it so it builds successfully. Tried w/ Python 3.4rc1 on Windows 7 w/ VS2010. Of course maybe it should really be building kill_python.exe for the matching architecture and running that, but I'm not sure how to do that and your fix is certainly far better than current behavior. -- ___ Python tracker <http://bugs.python.org/issue20609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine
Stephan R.A. Deibel added the comment: OK, sounds reasonable to me. -- ___ Python tracker <http://bugs.python.org/issue20609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1608921] PyThread_release_lock with pthreads munges errno
Stephan R.A. Deibel added the comment: If you are at PyCon 2009 sprints, try to see if you can find John Ehresman in the Python Core sprint to see it happen at line 115 of threadops.c in the Wing 3.2 source base. If you're not there or can't find him, I'll try to make a small example later. Feel free to email me directly also at sdeibel at wingware dot com. Note I saw this w/ pthreads and it may be that it does not occur under other threading implementations. -- ___ Python tracker <http://bugs.python.org/issue1608921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1608805] Py_FileSystemDefaultEncoding can be non-canonical
Stephan R.A. Deibel added the comment: It appears to be specific to 2.x and does not occur under Python 3.0: Python 3.0 (r30:67503, Jan 15 2009, 09:27:16) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.getfilesystemencoding() 'utf-8' Python 2.6.1 (r261:67515, Dec 11 2008, 11:59:39) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>import sys >>> sys.getfilesystemencoding() 'UTF-8' Python 2.5.4 (r254:67916, Mar 16 2009, 09:34:35) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.getfilesystemencoding() 'UTF-8' (This is on a Ubuntu system where LANG=en_US.UTF-8 is the default) -- ___ Python tracker <http://bugs.python.org/issue1608805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1608921] PyThread_release_lock with pthreads munges errno
Stephan R.A. Deibel added the comment: Here is a patch against Python 2.6.1 that restores errno after the "sanity check" in lock_PyThread_release_lock in Modules/threadmodule.c. A potential controversy is whether it should be done here or in thread_pthread.h but I believe that we should protect errno from spurious change by _any_ threading model that objects to this internal attempt to acquire an already acquired lock. -- keywords: +patch Added file: http://bugs.python.org/file13552/errno-fix.diff ___ Python tracker <http://bugs.python.org/issue1608921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1608921] PyThread_release_lock with pthreads munges errno
Stephan R.A. Deibel added the comment: He he, well my attempts at replicating this on Linux and OS X failed using Python 2.3->2.6 so I'm closing this bug. I'm uploading the test case for what it's worth. My best guess at what happened is that there was some interaction w/ older gdb, since I do know that I stepped through code in gdb to see this happen, or perhaps it was on older pthreads. The bug report dates from what I believe I had another desktop computer and older Linux version on that. Thanks for spurring me on to looking at this again and in more detail. -- status: open -> closed Added file: http://bugs.python.org/file13563/testcase.tgz ___ Python tracker <http://bugs.python.org/issue1608921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
