[issue30676] [Windows] Potential for GIL deadlock on Windows in threadmodule acquire_lock

2017-06-15 Thread Stephan R.A. Deibel
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

[issue30676] Potential for GIL deadlock on Windows in threadmodule acquire_lock

2017-06-15 Thread Stephan R.A. Deibel
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

[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine

2014-02-12 Thread Stephan R.A. Deibel
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

[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine

2014-02-12 Thread Stephan R.A. Deibel
Stephan R.A. Deibel added the comment: There's no patch attached... or am I just confused? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20609

[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine

2014-02-12 Thread Stephan R.A. Deibel
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

[issue20609] Always running kill_python breaks building x64 on 32-bit Windows machine

2014-02-12 Thread Stephan R.A. Deibel
Stephan R.A. Deibel added the comment: OK, sounds reasonable to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20609 ___ ___ Python-bugs

[issue13557] exec of list comprehension fails on NameError

2011-12-12 Thread Stephan R.A. Deibel
Stephan R.A. Deibel sdei...@wingware.com 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

[issue13557] exec of list comprehension fails on NameError

2011-12-09 Thread Stephan R.A. Deibel
Stephan R.A. Deibel sdei...@wingware.com 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

[issue13557] exec of list comprehension fails on NameError

2011-12-08 Thread Stephan R.A. Deibel
New submission from Stephan R.A. Deibel sdei...@wingware.com: 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

[issue13548] Invalid 'line' tracer event on pass within else clause

2011-12-07 Thread Stephan R.A. Deibel
New submission from Stephan R.A. Deibel sdei...@wingware.com: 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

[issue13548] Invalid 'line' tracer event on pass within else clause

2011-12-07 Thread Stephan R.A. Deibel
Stephan R.A. Deibel sdei...@wingware.com 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 rep...@bugs.python.org http://bugs.python.org

[issue1608921] PyThread_release_lock with pthreads munges errno

2009-04-01 Thread Stephan R.A. Deibel
Stephan R.A. Deibel sdei...@wingware.com 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

[issue1608921] PyThread_release_lock with pthreads munges errno

2009-03-31 Thread Stephan R.A. Deibel
Stephan R.A. Deibel sdei...@wingware.com 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

[issue1608805] Py_FileSystemDefaultEncoding can be non-canonical

2009-03-31 Thread Stephan R.A. Deibel
Stephan R.A. Deibel sdei...@wingware.com 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

[issue2198] code_hash() can be the same for different code objects

2008-02-27 Thread Stephan R.A. Deibel
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

[issue2198] code_hash() can be the same for different code objects

2008-02-27 Thread Stephan R.A. Deibel
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