[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
eryksun added the comment:
It is not clear why the absence of _setmode(fd, os.O_BINARY)
is not detected by tests.
It's only a problem when an existing text-mode file descriptor is passed in.
For example, in text mode the CRT handles b'\x1a' as an EOF marker:
Python 3.5.0b4 (v3.5.0b4:c0d641054635, Jul 26 2015, 07:11:12)
[MSC v.1900 64 bit (AMD64)] on win32
Type help, copyright, credits or license for more information.
import os, _pyio
_ = open('testfile', 'wb').write(b'abc\x1adef')
fd = os.open('testfile', os.O_RDONLY|os.O_TEXT)
f = _pyio.open(fd, 'rb')
f.read()
b'abc'
f.close()
f = _pyio.open('testfile', 'rb')
f.read()
b'abc\x1adef'
The setmode call ensures a file descriptor is in the expected binary mode:
import msvcrt
fd = os.open('testfile', os.O_RDONLY|os.O_TEXT)
old_mode = msvcrt.setmode(fd, os.O_BINARY)
old_mode == os.O_TEXT
True
f = _pyio.open(fd, 'rb')
f.read()
b'abc\x1adef'
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24881
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module
Changes by Josh Rosenberg shadowranger+pyt...@gmail.com: -- nosy: +josh.r ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24908] sysconfig.py and distutils.sysconfig.py disagree on directory spelling on Windows
New submission from Hartmut Niemann:
Lib\sysconfig.py uses '{installed_base}/Include'
as the include directory on Windows,
Lib\distutils\sysconfig.py uses
elif os.name == nt:
return os.path.join(prefix, include)
which is normally harmless because windows file systems
are case-preserving, but case-ignoring, but it leads to
a warning from pyinstaller:
https://github.com/pyinstaller/pyinstaller/issues/783
The directory referred to has a lowercase i (on my machine).
In my opinion both modules should use the spelling
that the installer uses when creating the directories.
--
messages: 248949
nosy: htnieman
priority: normal
severity: normal
status: open
title: sysconfig.py and distutils.sysconfig.py disagree on directory spelling
on Windows
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24908
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24352] Provide a way for assertLogs to optionally not hide the logging output
R. David Murray added the comment: My test harness already dumps the logging buffer on test failure. What I need this for is debugging. My test harness verbose = 2 flag turns on logging globally, and I need to see the logging from the code under test correctly interspersed with the other logging (some of which comes from *other processes*...there are integration tests as well as unit tests). Here's what I'm currently using: @contextmanager def assertLogs(self, logger=None, level=None): cm = super().assertLogs(logger, level) watcher = cm.__enter__() if verbose 1: capture_handler = cm.logger.handlers cm.logger.propagate = cm.old_propagate cm.logger.handlers = cm.old_handlers + cm.logger.handlers try: yield watcher finally: if verbose 1: # Restore before exit to avoid a race. Otherwise debug output # sometimes gets written to the console during non-v. cm.logger.propagate = False cm.logger.handlers = capture_handler cm.__exit__(None, None, None) So, I have a solution, and if my use case is too specialized I can just continue to use that solution, though I am forced to poke at the internals to make it work :) I am also, by the way, depending on the fact that when the logging is being done by another thread I can watch cm.output until specific logging that I am expecting appears in the buffer. I'm sure that's going to make some people throw up their hands in disgust, considering among other things the fact that it involves a busy-wait, but while it may be a somewhat ugly hack, it is a hack that works well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24352 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1384175] random module - Provider DLL failed to initialize correctly
eryksun added the comment:
I forgot to set errcheck:
import ctypes
userenv = ctypes.WinDLL('userenv', use_last_error=True)
def errcheck_bool(result, func, args):
if not result:
raise ctypes.WinError(ctypes.get_last_error())
return args
userenv.CreateEnvironmentBlock.argtypes = (ctypes.POINTER(ctypes.c_void_p),
ctypes.c_void_p,
ctypes.c_int)
userenv.DestroyEnvironmentBlock.argtypes = (ctypes.c_void_p,)
userenv.CreateEnvironmentBlock.errcheck = errcheck_bool
userenv.DestroyEnvironmentBlock.errcheck = errcheck_bool
# ...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1384175
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text
Mark Roseman added the comment: Just came across this one (Terry I'm sure can figure out why). I'm sympathetic with Guilherme's wish that Tk had done this one differently, as an option to specify an existing text widget peer when creating a text widget, rather than having the original spawn a new widget. It probably has something to do with specifying a -peer option that you couldn't later change via configure. As Gregory's peerfix.diff indicated, the original Python API for this command is wrong, or at least at odds with all the rest of Tkinter. The one required argument should indeed be the parent (master) for the new peer, and not it's widget path name. The call should return the new Text widget object. Given that nobody can be using the (unpatched) call as it is not functional, I suggest this be changed, without regard to backward compatibility concerns. The other issue that Gregory raises is the peer being an instance of a Text subclass, e.g. _textpeer, rather than Text itself. While I'm not certain, I suspect this could likely be an issue in practice. If it's somehow possible to create it as an instance of Text, that would definitely be preferable. I haven't closely examined BaseWidget et al., but I wonder if a hack along these lines might be possible: 1. Create a new Text widget under the parent (call it 'dummy') 2. Generate a new widget name (or used a passed in 'name' cnf parameter as usual) to be used for the peer text widget 3. Call the underlying 'peer create' with our generated name to create a new text widget on the Tcl side 4. Modify dummy._w to use the generated name 5. Replace the original parent.children[dummy._name] entry with one for the newly generated name 6. Call into Tcl to destroy the dummy Text widget It didn't look to me like there would be more housekeeping that needed doing to effectively point a widget object at a different widget. The overhead of temporarily creating the extra Text widget should be negligible in practice. If this seems like a feasible approach I can try to code it up. -- nosy: +markroseman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
Jake Garver added the comment: I agree. I couldn't find a use for the check, so I removed it entirely in the provided patch. I'm running that way now with success, but of course I'm covering just one use case. Digging back a bit further, the isdir() check came in here: https://github.com/python/cpython/commit/dc6a4c158f8a6175c7d0d5d1a61c24c06767ef22 And even further, near the beginning of time, we find the original check: https://github.com/python/cpython/commit/995d45ede2432306a2a0306ce29cea4013bc2850 Speculation: In the context of the original code, directory in the error message makes more sense and that word should have been dropped when single file support was added. However, given that we loop over the args, I don't see how -d was limited to a single arg. With my patch in place, I tested compileall.py with multiple args and the -d. It works as expected and contains the -d path. python -m compileall -d /runtime/path foo.py bar.py foobar.py I'm happy to craft a new patch. How would you like it? -- versions: -Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24903 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Question for Ryan Gonzalez: Given this information... On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee rep...@bugs.python.org wrote: Russell Keith-Magee added the comment: What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected. Does this mean I can safely ignore the segfault? Well, safely in the sense that everything except a very recent version of libffi is known to not work on ARM64 - so if it doesn't work, it's not because of something Python is doing wrong, it's a problem with a dependency. ...do you know of a way to run all tests except _ctypes, so that Imcan verify everything else? And to answer Russell's questions: Are you using the libffi sources vendored into the Python source tree, or a more recent version? By 'vendored in' do you mean 'sources included in python source tree for building?' Correct. The libffi source code that is in the Python source tree is quite old, and *definitely* doesn't work on ARM64. I'm not even sure that it works on ARMv7. Definitely using the vendored in sources. Would your recommend downloading and building libffi from sources (on device) and then building python? Well, for starters - as I've said before, I'd recommend not compiling on device at all, but that's a separate issue. Any particular reason why? The device I'm working with has a port of GCC which I've used to build other utilities that work well...given that I'm working on a tablet. However, regardless of where you're compiling, you can either use an external libffi, or you can do what I've done in the iOS patch - update the Python source tree to include a newer version of libffi. If you update the source in the Python tree, you need to use 2 versions (or a merged version); you need v3.2 sources for ARMv7, and trunk sources for ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk doesn't even compile for ARMv7. See the iOS patch for details. Since I'm not compiling for ARM64...and have zero experience with hacking configure.ac files...would it be okay to include just the 3.2 sources if I note somewhere that this fork does not include ARM64 support? I'm asking the above questions because I've hit a fairly significant roadblock; I'm still getting the segfault when test_ctypes is run and I can't seem to get anything useful out of gdb. Personally, I've pretty much given up on CPython on Android. Even when I got it working, the performance of the JNI layer is *abysmal*, and severely crippled. If you're planning to actually interact with the device in any way (like, say, put a button on the screen), that's a big problem. My goal is to build a port that operates on Android in a Linux-like environment; I'm currently using KBOX3. I've no experience with the Python language so JNI interop is Greek to me. For what i'm using the port for it functions fairly well. I'm working on an approach that uses Java natively - think Jython for Android. I'm still a way off having anything working, though. I'll keep an eye out for it once I've got Python basics under my belt. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment: On August 21, 2015 9:25:10 AM CDT, Cyd Haselton rep...@bugs.python.org wrote: Cyd Haselton added the comment: Question for Ryan Gonzalez: Given this information... On August 20, 2015 8:03:13 PM CDT, Russell Keith-Magee rep...@bugs.python.org wrote: Russell Keith-Magee added the comment: What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected. Does this mean I can safely ignore the segfault? Well, safely in the sense that everything except a very recent version of libffi is known to not work on ARM64 - so if it doesn't work, it's not because of something Python is doing wrong, it's a problem with a dependency. ...do you know of a way to run all tests except _ctypes, so that Imcan verify everything else? You can temporarily change the last line of Lib/ctypes/test/__init__.py to: return args[1] And to answer Russell's questions: Are you using the libffi sources vendored into the Python source tree, or a more recent version? By 'vendored in' do you mean 'sources included in python source tree for building?' Correct. The libffi source code that is in the Python source tree is quite old, and *definitely* doesn't work on ARM64. I'm not even sure that it works on ARMv7. Definitely using the vendored in sources. Would your recommend downloading and building libffi from sources (on device) and then building python? Well, for starters - as I've said before, I'd recommend not compiling on device at all, but that's a separate issue. Any particular reason why? The device I'm working with has a port of GCC which I've used to build other utilities that work well...given that I'm working on a tablet. However, regardless of where you're compiling, you can either use an external libffi, or you can do what I've done in the iOS patch - update the Python source tree to include a newer version of libffi. If you update the source in the Python tree, you need to use 2 versions (or a merged version); you need v3.2 sources for ARMv7, and trunk sources for ARM64. This is because libffi v3.2 doesn't work for ARM64, and trunk doesn't even compile for ARMv7. See the iOS patch for details. Since I'm not compiling for ARM64...and have zero experience with hacking configure.ac files...would it be okay to include just the 3.2 sources if I note somewhere that this fork does not include ARM64 support? I'm asking the above questions because I've hit a fairly significant roadblock; I'm still getting the segfault when test_ctypes is run and I can't seem to get anything useful out of gdb. Personally, I've pretty much given up on CPython on Android. Even when I got it working, the performance of the JNI layer is *abysmal*, and severely crippled. If you're planning to actually interact with the device in any way (like, say, put a button on the screen), that's a big problem. My goal is to build a port that operates on Android in a Linux-like environment; I'm currently using KBOX3. I've no experience with the Python language so JNI interop is Greek to me. For what i'm using the port for it functions fairly well. I'm working on an approach that uses Java natively - think Jython for Android. I'm still a way off having anything working, though. I'll keep an eye out for it once I've got Python basics under my belt. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1384175] random module - Provider DLL failed to initialize correctly
eryksun added the comment:
Albert, this issue was opened for Python 2.4 and was closed over 6 years ago.
Open a new issue if you believe there's a bug or room for improvement in a
currently supported Python version.
FYI, on Windows _PyOS_URandom first initializes the Crypto API by calling
[CryptAcquireContext][1]. As shown in the debug session below, this function
requires the SystemRoot environment variable to be correctly defined.
C:\cdb -g C:\Program Files\Python27\python.exe
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
...
import os
from ctypes import *
...
PROV_RSA_FULL = 1
CRYPT_VERIFYCONTEXT = 0xf000
CryptAcquireContextA = WinDLL('advapi32').CryptAcquireContextA
hcrypt = c_void_p()
del os.environ['SystemRoot']
CryptAcquireContextA(byref(hcrypt), None, None, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)
ModLoad: 07fe`fc48 07fe`fc498000
C:\Windows\system32\CRYPTSP.dll
CryptAcquireContext: CheckSignatureInFile failed at cryptapi.c line 5198
CryptAcquireContext: Failed to read registry signature value at cryptapi.c
line 873
0
os.environ['SystemRoot'] = 'C:\\Windows'
CryptAcquireContextA(byref(hcrypt), None, None, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)
ModLoad: 07fe`fc18 07fe`fc1c7000
C:\Windows\system32\rsaenh.dll
ModLoad: 07fe`fcae 07fe`fcaef000
C:\Windows\system32\CRYPTBASE.dll
1
hcrypt
c_void_p(4407952L)
It has always struck me as odd that this API uses the environment variable
instead of the object manager's secured \SystemRoot object symbolic link. C'est
la vie.
Anyway, I don't think Python's os and subprocess modules should prevent you
from shooting yourself in the foot here. When creating an environment block for
a child process, excluding SystemRoot is generally a bad idea, but the language
shouldn't get in the way.
I think it's prudent to include at least all of the system-defined variables.
Here's a function that calls [CreateEnvironmentBlock][2] and returns the system
variables in a dict. It excludes user variables and doesn't inherit from the
current process.
import ctypes
userenv = ctypes.WinDLL('userenv', use_last_error=True)
def errcheck_bool(result, func, args):
if not result:
raise ctypes.WinError(ctypes.get_last_error())
return args
userenv.CreateEnvironmentBlock.argtypes = (ctypes.POINTER(ctypes.c_void_p),
ctypes.c_void_p,
ctypes.c_int)
userenv.DestroyEnvironmentBlock.argtypes = (ctypes.c_void_p,)
def get_system_environ():
WCHAR_SIZE = ctypes.sizeof(ctypes.c_wchar)
environ = {}
cenv = ctypes.c_void_p()
userenv.CreateEnvironmentBlock(ctypes.byref(cenv), None, 0)
addr = cenv.value
try:
while True:
s = ctypes.c_wchar_p(addr).value
if not s:
break
i = s.find('=', 1)
if i != -1:
environ[s[:i]] = s[i+1:]
addr += (len(s) + 1) * WCHAR_SIZE
finally:
userenv.DestroyEnvironmentBlock(cenv)
return environ
[1]: https://msdn.microsoft.com/en-us/library/aa379886
[2]: https://msdn.microsoft.com/en-us/library/bb762270
--
nosy: +eryksun
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1384175
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1384175] random module - Provider DLL failed to initialize correctly
Albert Zeyer added the comment: Ah thanks, that explains why it failed for me, and why it works after my fix, which was anyway what I intended. I mostly posted my comment here in case someone else hits this, so he has another thing to check/debug. I don't think that there is a bug on Python's side. Maybe a nice thing would be a small check in _PyOS_URandom for os.environ['SystemRoot'] and print a more helpful error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1384175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24908] sysconfig.py and distutils.sysconfig.py disagree on directory spelling on Windows
eryksun added the comment: Within the standard library, I think only the site module uses the top-level sysconfig module, which IIRC it uses to set up sys.path. Note that WINDOWS_SCHEME in distutils.command.install uses Include. Also for virtual environments, venv.EnvBuilder.ensure_directories hard codes Include. -- components: +Distutils, Windows nosy: +dstufft, eric.araujo, eryksun, paul.moore, steve.dower, tim.golden, zach.ware priority: normal - low type: - behavior versions: +Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24908 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
Changes by R. David Murray rdmur...@bitdance.com: -- versions: +Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24903 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19084] No way to use TLS-PSK from python ssl
Changes by Nicolas Jouanin n...@beerfactory.org: -- nosy: +njouanin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19084 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
Adam Meily added the comment: Attached is a test Python script that you can run to see the race condition in action. There are two Python scripts: pipe.py and reader.py. - pipe.py: make two subprocess.Popen() calls from two different threads. - reader.py: (its content is in the bottom comments of pipe.py, so move it to a separate file): reads lines from stdin and exits Basically, pipe.py creates a pipe between echo Hello World! and python reader.py. You'll see that pipe.py will hang until ctrl+c is entered, even though the first subprocess in the pipe, reader.py, exits. Uncommenting the time.sleep() call will cause the first subprocess.Popen() time to properly close the inheritable handles before the second subprocess.Popen() call is made in the other thread, thus the inheritable handles are leaked. -- Added file: http://bugs.python.org/file40220/pipe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11943] Add TLS-SRP (RFC 5054) support to ssl, _ssl, http, and urllib
Changes by Nicolas Jouanin n...@beerfactory.org: -- nosy: +njouanin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
New submission from Adam Meily: ** This issue and attached patch only affect Windows ** Currently, the Popen constructor will duplicate any stdout, stdin, and/or stderr handle passed in and make them inheritable, by calling DuplicateHandle. If two threads call Popen at the same time, the newly created inheritable handles will leak into the subprocess that's running being created in the opposite thread. This has consequences when two or more subprocesses are piped together and executed at the time time. Example === A pipe is created using the os.pipe() function. Then, two threads are started, T1 and T2. T1 calls Popen, setting stdout to the write-end of the pipe. T2 calls Popen, setting stdin to the read-end of the pipe. Stock CPython would make T1.stdout and T2.stdin inheritable. T1's Popen will create a subprocess, which correctly inherits T1.stdout, but it will also inherit the T2.stdin handle. Likewise, T2's Popen will create a subprocess, which correctly inherits T2.stdin, but it will also inherit the T1.stdout handle. Thus, in this situation where both ends of the pipe were accidentally inherited, the pipe will not properly close and T2's subprocess will have to be forcefully killed (assuming it is reading from stdin). The patch simply enforces that the lifetime of an inheritable handle is limited to a single call to Popen. Why this should be in CPython = I believe this change should be in CPython. Tracking down this bug into the Python core took a substantial amount of time and work. Can I do this in my Python application and achieve the same effect? Absolutely, but I would argue that I shouldn't have to. The fix in CPython is very minimal: - It won't break existing code. Even if my project already has a lock around calls to Popen, my code will continue to work. Sure, it's a duplicate lock, but nothing will break or deadlock. - The performance impact is negligible. The lock is only instantiated for Windows platforms and acquiring/releasing a lock appears to have very low overhead. - Because the patch is very small, it can be easily backported to other Python versions. As far as I can tell, Python 3.5, 3.4, 3.3, and 2.7 will work with the attached patch. The one difference between the Python versions is that subprocess.mswindows was renamed to subprocess._mswindows at some point, which is very minor. - Python 3.4's new OS-specific inheritable functions [os.get_inheritable(), os.set_inheritable(), etc] will continue to work as expected. So, nothing is broken or changed there. Old code won't break, new code will benefit immediately, and existing code will work better. Similar Issues == - #19809: subprocess should warn uses on race conditions when multiple threads spawn child processes - #2320: Race condition in subprocess using stdin - #12739: read stuck with multithreading and simultaneous subprocess.Popen -- components: Library (Lib) files: win32-popen-lock.patch keywords: patch messages: 248961 nosy: Adam Meily priority: normal severity: normal status: open title: Windows: subprocess.Popen: race condition for leaking inheritable handles type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40219/win32-popen-lock.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
R. David Murray added the comment: Is it possible to construct a test for this? -- components: +Windows nosy: +gregory.p.smith, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware stage: - patch review versions: -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
R. David Murray added the comment: OK, so I think the goal was to prevent more than one *directory* from being specified, since as I said earlier that wouldn't make sense given we have only a single destdir path. However, for backward compatibility reasons we should probably not restrict it, but rather invoke the python consenting adults rule and let you shoot yourself in the foot that way if you want to. It only affects error messages, after all. So yeah, if you can build a new patch including some tests that would be great. Best way is to check out the repository, switch to the 3.4 branch, edit the files, and use 'hg diff' to generate the patch. Doing it that way makes it easy to test your changes. But whatever method of coming up with a context diff that you care to use is also fine. More detailed information about the normal workflow is in docs.python.org/devguide. Note that in addition to the central repository at hg.python.org, there are also bitbucket and github mirrors, which should both be mentioned in the devguide (if they aren't, that's a bug in the devguide :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24903 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24907] Module location load order is not respected if pkg_resources is imported and a namespace is declared
R. David Murray added the comment: pkg_resources is 3rd party code (from the point of view of this tracker). If you are saying its code is revealing a bug in python, can you expand on what exactly the bug is? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +haypo, serhiy.storchaka versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24881 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment: Bus error is basically unaligned memory access. ... ...do you feel like trying to get a backtrace from GDB again? :) (The last time likely didn't end well because the machine stack got somehow corrupted.) On Fri, Aug 21, 2015 at 2:04 PM, Cyd Haselton rep...@bugs.python.org wrote: Cyd Haselton added the comment: Thanks Ryan. Running ./python -m test (with the edit to the __init__.py for ctypes) produces the following error: [151/390/18] test_hash Fatal Python error: Bus error Current thread 0xb6f72ec8 (most recent call first): File /bld/pyt/cpython-android/Lib/test/test_hash.py, line 89 in test_unaligned_buffers File /bld/pyt/cpython-android/Lib/unittest/case.py, line 577 in run File /bld/pyt/cpython-android/Lib/unittest/case.py, line 625 in __call__ File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 122 in run File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 84 in __call__ File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 122 in run File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 84 in __call__ File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 122 in run File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 84 in __call__ File /bld/pyt/cpython-android/Lib/test/support/__init__.py, line 1668 in run File /bld/pyt/cpython-android/Lib/test/support/__init__.py, line 1769 in _run_suite File /bld/pyt/cpython-android/Lib/test/support/__init__.py, line 1803 in run_unittest File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 1279 in test_runner File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 1280 in runtest_inner File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 978 in runtest File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 763 in main File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 1564 in main_in_temp_cwd File /bld/pyt/cpython-android/Lib/test/__main__.py, line 3 in module File /bld/pyt/cpython-android/Lib/runpy.py, line 85 in _run_code File /bld/pyt/cpython-android/Lib/runpy.py, line 170 in _run_module_as_main Bus error Not sure what a bus error is...off to Google -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
Adam Meily added the comment: Ok, I can re-implement the patch to meet what you all are looking for. I just want to double check that I'm on the same page: I'll get rid of the lock, because the fix should really be done in the call to CreateProcessW. I imagine that I'll be editing Modules/_winapi.c:824. Essentially, the fix will include switching _winapi.c to use a STARTUPINFOEX structure, and manually passing in the three handles for stdin, stdout, and stderr to PROC_THREAD_ATTRIBUTE_HANDLE_LIST. The one potential problem that I see is that it looks like specifying PROC_THREAD_ATTRIBUTE_HANDLE_LIST means that no other handles are inherited, even if they are inheritable. Doesn't this break applications that are explicitly creating inheritable handles and expecting them to be accessible within the subprocess? I could add Windows support for pass_fds, but then existing applications would have to be updated to use the argument on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
Akira Li added the comment:
To make _pyio correspond to the C version I've added
sys.platform in {'win32', 'cygwin'}
condition. See the attached pyio_setmode.diff
It is not clear why the absence of _setmode(fd, os.O_BINARY) is not detected by
tests.
(a) a corresponding test should be added
(b) OR _setmode() call should be removed from both Python and C io versions
--
keywords: +patch
nosy: +akira
Added file: http://bugs.python.org/file40222/pyio_setmode.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24881
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19469] Duplicate namespace package portions (but not on Windows)
Brett Cannon added the comment: I can't reproduce under Python 3.4.3, the 3.4 branch, 3.5 branch, or default with a plain namespace package. Can anyone come up with a test case that can reproduce this problem? Otherwise I'll assume it was a bug that got fixed in 3.4.2. -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19469 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17945] tkinter: change API of non-functioning peer_create, does not instantiate Text
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +serhiy.storchaka title: tkinter/Python 3.3.0: peer_create doesn't instantiate Text - tkinter: change API of non-functioning peer_create, does not instantiate Text type: behavior - enhancement versions: +Python 3.6 -Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24848] Warts in UTF-7 error handling
Serhiy Storchaka added the comment:
There is a reason for behavior in case 2. This is likely a truncated data and
it is safer to raise an exception than silently produce lone surrogate. Current
UTF-7 encoder always adds '-' after ending shift sequence. I suppose this is
not a bug.
However there are yet three bugs.
4. Decoder can emit lone low surrogate before replacement character in case of
error.
b'+2DTdI-'.decode('utf-7', 'replace')
'\ud834�'
A low surrogate is a part of incomplete astral character and shouldn't emitted
in case of error in encoded astral character.
5. According to RFC 2152: A + character followed immediately by any
character other than members of set B or - is an ill-formed sequence. But
this is accepted by current decoder as empty shift sequence that is decoded to
empty string.
b'a+,b'.decode('utf-7')
'a,b'
b'a+'.decode('utf-7')
'a'
6. Replacement character '\ufffd' can be replaced with character 'ý' ('\xfd'):
b'\xff'.decode('utf-7', 'replace')
'�'
b'a\xff'.decode('utf-7', 'replace')
'a�'
b'a\xffb'.decode('utf-7', 'replace')
'a�b'
b'\xffb'.decode('utf-7', 'replace')
'ýb'
This bug is reproduced only in 3.4+.
Following patch fixes bugs 1 and 4 and adds more tests.
Corner cases 2 and 3 are likely not bugs.
I doubt about fixing bug 5. iconv accepts such ill-formed sequences. In any
case I think the fix of this bug can be applied only for default branch.
I have no idea how to fix bug 6. I afraid it can be a bug in _PyUnicodeWriter
and therefore can affect other decoders.
--
keywords: +patch
stage: - patch review
Added file: http://bugs.python.org/file40223/utf7_error_handling.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24848
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24911] Context manager of socket.socket is not documented
New submission from zodalahtathi: socket.socket has a context manager to automatically close the socket with the `with` statement: https://hg.python.org/cpython/file/d1bf181afa82/Lib/socket.py#l138 However it is not documented, unlike socket.create_connection. -- assignee: docs@python components: Documentation messages: 248979 nosy: docs@python, zodalahtathi priority: normal severity: normal status: open title: Context manager of socket.socket is not documented versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8987] Distutils doesn't quote Windows command lines properly
Chris Hogan added the comment: Here's a change that might fix the trailing backslash problem for now without breaking anything. libpath-fix.patch only affects arguments that we know are paths. This happens before anything is quoted. This avoids the problem when something like 'C:\path with space\trailing backslash\' is passed to _nt_quote_args() and becomes 'C:\path with space\trailing backslash\'. The is escaped which mangles the string. I'm not sure if it's the responsibility of the user to not pass in such arguments, or of cpython to sanitize these things. Is this change harmless, or can you think of situations where it will break something? -- Added file: http://bugs.python.org/file40221/libpath-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8987 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24907] Module location load order is not respected if pkg_resources is imported and a namespace is declared
Changes by Brett Cannon br...@python.org: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24907 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text
Mark Roseman added the comment: Did a quick check... this approach seems to work. Only change was in step 4 should set both ._w and ._name for the widget object -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17945 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24910] Windows MSIs don't have unique display names
New submission from Steve Dower: The MSIs for debug symbols and binaries have the same descriptions as the main installers, so you can't distinguish between the packages in lists like (get-package python).Name (in Powershell): Python 3.5.0rc1 Development Libraries (64-bit) Python 3.5.0rc1 Core Interpreter (64-bit) Python 3.5.0rc1 Standard Library (32-bit) Python 3.5.0rc1 Executables (64-bit) Python 3.5.0rc1 Executables (32-bit) Python 3.5.0rc1 Tcl/Tk Support (32-bit) Python 3.5.0rc1 Tcl/Tk Support (64-bit) Python 3.5.0rc1 Executables (32-bit) Python 3.5.0rc1 Tcl/Tk Support (32-bit) Python 3.5.0rc1 Tcl/Tk Support (64-bit) Python 3.5.0rc1 Standard Library (32-bit) Python 3.5.0rc1 Tcl/Tk Support (32-bit) Python 3.5.0rc1 Core Interpreter (32-bit) Python 3.5.0rc1 Core Interpreter (64-bit) We (I) should fix up the descriptions so they can be told apart. (Note that these are not generally user-visible, so it isn't a huge deal.) -- assignee: steve.dower components: Installation, Windows messages: 248972 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Windows MSIs don't have unique display names type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
STINNER Victor added the comment: Yeah, when stdin, stdout or stderr is a pipe, subprocess.Popen() calls CreateProcess() with the STARTF_USESTDHANDLES flag and bInheritHandles=TRUE. This issue was fixed on UNIX for file descriptor inheritance. The fix is a major change: Python 3.4 now only creates non-inheritable file descriptors by default. See the PEP 446. For your issue, see the Only Inherit Some Handles on Windows section: https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows But this section is not fixed by the PEP. I was decided to fix inheritance of file descriptors and inheritance of handles separatly. I guess that this issue is a duplicate of the issue #19575. I'm against the idea of adding a lock inside the subprocess module. I may introduce deadlock issues. You can already put such lock in your application, to call subprocess.Popen (directly or indirectly). Currently, the Popen constructor will duplicate any stdout, stdin, and/or stderr handle passed in and make them inheritable, by calling DuplicateHandle. If two threads call Popen at the same time, the newly created inheritable handles will leak into the subprocess that's running being created in the opposite thread. This has consequences when two or more subprocesses are piped together and executed at the time time. This is a race condition really specific to the subprocess module. Usually, handles are created non-inhertable on Windows, so calling CreateProcess() with bInheritHandles=TRUE is not an issue in the common case. Here the problem is that subprocess makes duplicated handles inheritable. There is a short window where a second thread can spawn a process and inherit these handles too. The real fix is to never make duplicated handles inheritable, but instead to use the new PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure. Another option to fix the issue is to use a wrapper application and send handles from the parent to the child, but this option introduces a lot of complexity since the parent has to handle two processes, not only one! Again, see the issue #19575. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
Adam Meily added the comment: @r.david.murray: Yes I could make a test. @haypo: I did not know about the PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure, thanks for the heads up. You pointed me in the right direction, and I see now that you've been following this, and similar, subprocessing issues on Windows for some time. I understand the hesitancy for adding a Lock to the standard library. Unless I am mistaken, I don't think my patch could cause a deadlock. I am releasing the lock in a `finally` block. So, the way I see it, the only way a deadlock can occur is if the thread crashes while in C code, which will cause the `finally` block to not execute. The lock will stay acquired, and then another thread will deadlock trying to acquire the lock. However, if that is the case and the thread crashed in C, the whole interpreter instance would have crashed, not just the Thread, which would make the deadlock impossible. It looks like the structure you reference to, PROC_THREAD_ATTRIBUTE_HANDLE_LIST (STARTUPINFOEX), is only available in Windows Vista and after. Which means that Windows XP/Server 2003 would still have this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
STINNER Victor added the comment: Yeah, when stdin, stdout or stderr is a pipe, subprocess.Popen() calls CreateProcess() with the STARTF_USESTDHANDLES flag and bInheritHandles=TRUE. This issue was fixed on UNIX for file descriptor inheritance. The fix is a major change: Python 3.4 now only creates non-inheritable file descriptors by default. See the PEP 446, especially the Only Inherit Some Handles on Windows section: https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows This part is out of the scope of the PEP. For me, the real fix would be to create non-inheritable I guess that this issue is a duplicate of the issue #19575. I'm again the idea of adding a lock inside the subprocess module. I may add deadlocks. You can already put this lock in your application, before calling subprocess.Popen (directly or indirectly). Currently, the Popen constructor will duplicate any stdout, stdin, and/or stderr handle passed in and make them inheritable, by calling DuplicateHandle. If two threads call Popen at the same time, the newly created inheritable handles will leak into the subprocess that's running being created in the opposite thread. This has consequences when two or more subprocesses are piped together and executed at the time time. This is a race condition specific to the subprocess module. Usually, handles are created non-inhertable, so calling CreateProcess() with bInheritHandles=TRUE is not an issue. The real fix is *not* make duplicated handles inheritable, but use the new PROC_THREAD_ATTRIBUTE_HANDLE_LIST structure. Again, see the issue #19575. -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue993766] bdist_dumb and --relative on Windows fails
Chris Hogan added the comment:
I think ensure_relative is incorrect. The comment in the function states:
Take the full path 'path', and make it a relative path. This is useful to
make 'path' the second argument to os.path.join().
However, according to the docs for os.path.join, if a component contains a
drive letter, all previous components are thrown away and the drive letter is
reset. This makes the result from ensure_relative a poor candidate as a
second argument to os.path.join on Windows because it will always contain a
drive letter which will always wipe out the first argument.
os.path.join('bar', 'c:foo')
'c:foo'
This is what happens when I try to build a simple distro with the command
python setup.py bdist_dumb --relative. In
Lib/distutils/command/bdist_dumb.py:bdist_dumb.run:
archive_root = os.path.join(self.bdist_dir,
ensure_relative(install.install_base))
the call is
os.path.join('build\\bdist.win-amd64\\dumb', 'C:path\\to\\python')
'C:path\\to\\python'
It seems to me that the intention is to return
'build\\bdist.win-amd64\\dumb\\path\\to\\python27'
Later in distutils.archive_util.make_archive, it tries to os.chdir into
'C:path\\to\\python', which it can't do because that's not an absolute path
(it's missing a '\' after 'C:').
As far as I can tell, the only thing the --relative flag does is to append the
python install path onto the build location and build the archive there.
However, this build location is temporary and gets deleted at the end of the
process, so I don't really see the point.
I think there are two options here:
1) Get rid of ensure_relative and do it like this:
archive_root = os.path.join(self.bdist_dir,
os.path.splitdrive(install.install_base)[1].lstrip(os.sep))
This is the only place ensure_relative is ever used anyway.
2) Keep ensure_relative and do it like this:
archive_root = os.path.join(self.bdist_dir,
os.path.splitdrive(ensure_relative(install.install_base))[1])
--
nosy: +christopher.hogan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue993766
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
STINNER Victor added the comment: It looks like the structure you reference to, PROC_THREAD_ATTRIBUTE_HANDLE_LIST (STARTUPINFOEX), is only available in Windows Vista and after. Which means that Windows XP/Server 2003 would still have this issue. Windows XP is no more supported in Python 3.5: https://docs.python.org/dev/whatsnew/3.5.html#unsupported-operating-systems For Windows Server 2003, yes, we will have to keep the current code which has the race condition. We did the same in the PEP 446 to clear the inherit flag. It's atomic or not depending on the function, on the operating system and even depending on the operating system version. So the PEP 446 doesn't fix all race conditions on old operating systems. https://www.python.org/dev/peps/pep-0446/#atomic-creation-of-non-inheritable-file-descriptors -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Thanks Ryan. Running ./python -m test (with the edit to the __init__.py for ctypes) produces the following error: [151/390/18] test_hash Fatal Python error: Bus error Current thread 0xb6f72ec8 (most recent call first): File /bld/pyt/cpython-android/Lib/test/test_hash.py, line 89 in test_unaligned_buffers File /bld/pyt/cpython-android/Lib/unittest/case.py, line 577 in run File /bld/pyt/cpython-android/Lib/unittest/case.py, line 625 in __call__ File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 122 in run File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 84 in __call__ File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 122 in run File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 84 in __call__ File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 122 in run File /bld/pyt/cpython-android/Lib/unittest/suite.py, line 84 in __call__ File /bld/pyt/cpython-android/Lib/test/support/__init__.py, line 1668 in run File /bld/pyt/cpython-android/Lib/test/support/__init__.py, line 1769 in _run_suite File /bld/pyt/cpython-android/Lib/test/support/__init__.py, line 1803 in run_unittest File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 1279 in test_runner File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 1280 in runtest_inner File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 978 in runtest File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 763 in main File /bld/pyt/cpython-android/Lib/test/regrtest.py, line 1564 in main_in_temp_cwd File /bld/pyt/cpython-android/Lib/test/__main__.py, line 3 in module File /bld/pyt/cpython-android/Lib/runpy.py, line 85 in _run_code File /bld/pyt/cpython-android/Lib/runpy.py, line 170 in _run_module_as_main Bus error Not sure what a bus error is...off to Google -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
Changes by STINNER Victor victor.stin...@gmail.com: -- Removed message: http://bugs.python.org/msg248964 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19469] Duplicate namespace package portions (but not on Windows)
Carl Meyer added the comment: FWIW, this bug has bitten Django; see https://code.djangoproject.com/ticket/25246 We can easily work around it for future versions, but we have code in released versions that assumed that `__path__` wouldn't contain dupes; it causes us to raise an error in a situation that shouldn't be an error (because we need a Django app module to have exactly one filesystem location). -- nosy: +carljm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19469 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles
Zachary Ware added the comment: STINNER Victor added the comment: For Windows Server 2003, yes, we will have to keep the current code which has the race condition. Server 2003 is also unsupported in 3.5+ (MS extended support ended in July). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24913] newblock() Uninitialized Variable
New submission from John Leitch:
Python 3.5 suffers from a vulnerability caused by the behavior of the
newblock() function used by the collections.deque module. When called,
newblock() allocates memory using PyMem_Malloc() and does not initialize it:
static block *
newblock(Py_ssize_t len) {
block *b;
if (len = MAX_DEQUE_LEN) {
PyErr_SetString(PyExc_OverflowError,
cannot add more blocks to the deque);
return NULL;
}
if (numfreeblocks) {
numfreeblocks--;
return freeblocks[numfreeblocks];
}
b = PyMem_Malloc(sizeof(block)); Memory allocation.
if (b != NULL) {
return b; Buffer returned without initialization.
}
PyErr_NoMemory();
return NULL;
}
Because PyMem_Malloc does not initialize the memory, the block may contain
garbage data. In some cases, this can lead to memory corruption which could be
exploitable to achieve code execution. The following exception analysis is an
example of EIP corruption:
***
* *
*Exception Analysis *
* *
***
*** The OS name list needs to be updated! Unknown Windows version: 10.0 ***
FAULTING_IP:
python35!PyUnicode_Type+0
696f60d8 a800testal,0
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 696f60d8 (python35!PyUnicode_Type)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]: 0008
Parameter[1]: 696f60d8
Attempt to execute non-executable address 696f60d8
CONTEXT: -- (.cxr 0x0;r)
eax=696f60d8 ebx=0002 ecx=00d9492c edx=0002 esi=019b4e58 edi=0337b970
eip=696f60d8 esp=00bcf7dc ebp=00bcf7fc iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
python35!PyUnicode_Type:
696f60d8 a800testal,0
PROCESS_NAME: pythonw.exe
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%p referenced memory
at 0x%p. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%p referenced
memory at 0x%p. The memory could not be %s.
EXCEPTION_PARAMETER1: 0008
EXCEPTION_PARAMETER2: 696f60d8
WRITE_ADDRESS: 696f60d8
FOLLOWUP_IP:
python35!PyUnicode_Type+0
696f60d8 a800testal,0
FAILED_INSTRUCTION_ADDRESS:
python35!PyUnicode_Type+0
696f60d8 a800testal,0
APP: pythonw.exe
ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre
FAULTING_THREAD: 09dc
DEFAULT_BUCKET_ID: SOFTWARE_NX_FAULT_CODE
PRIMARY_PROBLEM_CLASS: SOFTWARE_NX_FAULT_CODE
BUGCHECK_STR:
APPLICATION_FAULT_SOFTWARE_NX_FAULT_CODE_SOFTWARE_NX_FAULT_FALSE_POSITIVE
LAST_CONTROL_TRANSFER: from 69505ad3 to 696f60d8
STACK_TEXT:
00bcf7fc 69505ad3 0002 00bcf840 694253fc python35!PyUnicode_Type
00bcf808 694253fc 0337b970 019b4e58 0002 python35!PyObject_RichCompare+0x53
00bcf840 695031c3 03a1a8f0 03a21878 00f83340 python35!deque_index+0xac
00bcf85c 69564433 03a21120 03a21878 python35!PyCFunction_Call+0x113
00bcf890 695618d8 00e23a08 0040 python35!call_function+0x303
00bcf908 6956339f 00e23a08 00f83000 python35!PyEval_EvalFrameEx+0x2318
00bcf954 6959a142 00e40f58
python35!_PyEval_EvalCodeWithName+0x82f
00bcf990 69599fd5 00e40f58 00e40f58 00bcfa5c python35!run_mod+0x42
00bcf9bc 6959904a 00f801f0 00e366f0 0101 python35!PyRun_FileExFlags+0x85
00bcfa00 6946f037 00f801f0 00e366f0 0001
python35!PyRun_SimpleFileExFlags+0x20a
00bcfa2c 6946f973 00bcfa5c 6ecb2100 python35!run_file+0xe7
00bcfad4 1ce31279 0002 00f79eb0 1ce3c588 python35!Py_Main+0x913
00bcfae4 1ce3145f 1ce3 00f71c68 pythonw!wWinMain+0x19
00bcfb30 74ed3744 7f174000 74ed3720 5c8b59d2 pythonw!__scrt_common_main_seh+0xfd
00bcfb44 775aa064 7f174000 a81800d2 kernel32!BaseThreadInitThunk+0x24
00bcfb8c 775aa02f 775cd7c3 ntdll!__RtlUserThreadStart+0x2f
00bcfb9c 1ce3150a 7f174000 ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND: ~0s; .ecxr ; kb
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: python35!PyUnicode_Type+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: python35
IMAGE_NAME: python35.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 5598ccc2
FAILURE_BUCKET_ID: SOFTWARE_NX_FAULT_CODE_c005_python35.dll!PyUnicode_Type
BUCKET_ID:
APPLICATION_FAULT_SOFTWARE_NX_FAULT_CODE_SOFTWARE_NX_FAULT_FALSE_POSITIVE_BAD_IP_python35!PyUnicode_Type+0
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING:
um:software_nx_fault_code_c005_python35.dll!pyunicode_type
FAILURE_ID_HASH: {aa94d074-8f9b-b618-df4f-eaad15f84370}
Followup:
[issue24913] newblock() Uninitialized Variable
Changes by John Leitch john.leit...@gmail.com: Added file: http://bugs.python.org/file40225/newblock_Uninitialized_variable.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24913 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24913] newblock() Uninitialized Variable
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24913 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24907] Module location load order is not respected if pkg_resources is imported and a namespace is declared
New submission from Vadim Kantorov:
If module's __init__.py contains
__import__('pkg_resources').declare_namespace(__name__), the module is not
loaded, even though it's located in the current directory and should mask other
modules.
Originally I stumbled upon this issue while installing a new version of Google
Protobuf. But here's a simpler repro:
$ python -c 'import json; print json.__file__'
/usr/lib/python2.7/json/__init__.pyc
$ mkdir json; echo print 'test' json/__init__.py
$ python -c 'import json; print json.__file__'
test
json/__init__.py
$ echo __import__('pkg_resources').declare_namespace(__name__); print 'test'
json/__init__.py
$ python -c 'import json; print json.__file__'
test
/usr/lib/python2.7/json/__init__.pyc
For Protobuf, if you build Python bindings from sources, the google/__init__.py
will contain exactly __import__('pkg_resources').declare_namespace(__name__)
and it prevents the freshly-built module from being loaded, even if the module
egg is at the first place in sys.path. So an older version gets loaded and it
screws things up.
Ubuntu 14.10, Python 2.7.8
--
components: Extension Modules
messages: 248948
nosy: Vadim Kantorov
priority: normal
severity: normal
status: open
title: Module location load order is not respected if pkg_resources is imported
and a namespace is declared
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24907
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24906] asyncore asynchat hanging on ssl
New submission from Michele Comitini: When sending a message larger than 4096 bytes with smtpd on a ssl socket, everything hangs. This is due to polling before synchronizing the SSL channel with the underlying socket. The issue can be solved by properly modifying the poll function and handling the SSLWantRead exception. I provide 2 (Debug)SMTPServer implementations and one client to show the error and the workaround all using ssl. The workaround is not correct semantically but fixes the poll function behavior correctly. -- components: Library (Lib) files: async-ssl-bug.zip messages: 248946 nosy: Michele Comitini priority: normal severity: normal status: open title: asyncore asynchat hanging on ssl type: crash versions: Python 2.7 Added file: http://bugs.python.org/file40218/async-ssl-bug.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1384175] random module - Provider DLL failed to initialize correctly
Albert Zeyer added the comment:
Note that there are still people who get this error in some strange cases, me
included.
E.g.:
http://stackoverflow.com/questions/27904936/python-exe-file-crashes-while-launching-on-windows-xp/32137554#32137554
This happened at a call to `os.urandom` for me.
This was in a subprocess.
The bug for me was that I called `_subprocess.CreateProcess` with an
`env_mapper = {'foo': 'bar'}`. The fix:
env_mapper = os.environ.copy()
env_mapper.update({'foo': 'bar'})
There is another related question
[here](http://stackoverflow.com/questions/21791005/windows-error-provider-dll-failed-to-initialize-correctly-on-import-of-cgi-mo).
And some discussion on [this GitHub
issue](https://github.com/aws/aws-cli/issues/1226).
All those seem to be related to `crypt32.dll` in a frozen Python app, or via
py2app.
--
nosy: +Albert.Zeyer
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1384175
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24905] Allow incremental I/O to blobs in sqlite3
New submission from Jim Minter: SQLite supports incremental I/O to blobs, i.e. the capability to stream reads and writes to blobs without having to load the entire blob into memory first. See https://www.sqlite.org/c3ref/blob_open.html for more details on the C API. It'd be nice if it were possible to do this in Python using sqlite3 (it is already possible with apsw). -- messages: 248945 nosy: jim_minter priority: normal severity: normal status: open title: Allow incremental I/O to blobs in sqlite3 type: enhancement versions: Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24905 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
