[issue31712] subprocess with stderr=subprocess.STDOUT hang

[l4mer]

l4mer  added the comment:

janusz@nc6120:~$ ssh -V
OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
janusz@nc6120:~$

I) manual check

janusz@nc6120:~$ ssh root@localhost -p 50494 -O exit
janusz@nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> cmd = ["ssh", "root@localhost", "-p", "50494"]
>>> buf = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
Terminated

janusz@nc6120:~$ ssh root@localhost -p 50494 -O exit
Exit request sent.
janusz@nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd= ["ssh", "root@localhost", "-p", "50494"]
>>> buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
Terminated

II) strace 

Correct case (mux exist):
pipe2([3, 4], O_CLOEXEC)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0xb747a768) = 2207
close(6)= 0
close(4)= 0
brk(0x9741000)  = 0x9741000
read(5, "", 5)  = 0
brk(0x9735000)  = 0x9735000
close(5)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
_llseek(3, 0, 0xbfc1d350, SEEK_CUR) = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)= 5
read(3, "", 1)  = 0
close(3)= 0
waitpid(2207, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 2207
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2207, si_uid=1000, 
si_status=0, si_utime=0, si_stime=0} ---
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x8183c10, [], 0}, 8) = 0
brk(0x9733000)  = 0x9733000
exit_group(0)   = ?
+++ exited with 0 +++

Fail case:
read(7, "menting schedulers (this is what"..., 8192) = 8192
read(7, "\0\0\0_lent\1\0\0\0ht\10\0\0\0h_appendt\5\0\0\0i"..., 4096) = 2240
read(7, "", 4096)   = 0
close(7)= 0
mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb70c7000
close(6)= 0
close(5)= 0
close(4)= 0
ugetrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
close(3)= 0
pipe2([3, 4], O_CLOEXEC)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0xb7539768) = 2238
close(6)= 0
close(4)= 0
brk(0xa30e000)  = 0xa30e000
read(5, "", 5)  = 0
brk(0xa302000)  = 0xa302000
close(5)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
_llseek(3, 0, 0xbf8a0600, SEEK_CUR) = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)= 5
read(3, 0xb710db19, 1)  = ? ERESTARTSYS (To be restarted if 
SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2238, si_uid=1000, 
si_status=0, si_utime=4, si_stime=1} ---
read(3,
d(3, ^Cstrace: Process 2237 detached
 
janusz@nc6120:~$ Traceback (most recent call last):
  File "test.py", line 6, in 
buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 628, in 
check_output
output, unused_err = process.communicate(timeout=timeout)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 915, in 
communicate
stdout = _eintr_retry_call(self.stdout.read)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 543, in 
_eintr_retry_call
return func(*args)
KeyboardInterrupt

When hang:
janusz@nc6120:~$ ls -l "/proc/$(pgrep python)/fd/3"
lr-x-- 1 janusz janusz 64 paź  7 10:25 /proc/2336/fd/3 -> pipe:[29858]
janusz@nc6120:~$ lsof |grep 29858
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/108/gvfs
  Output information may be incomplete.
python2336janusz3r FIFO   0,10  0t0  
29858 pipe
ssh   2342janusz2w FIFO   0,10  0t0  
29858 pipe
janusz@nc6120:~$

--

___
Python tracker 

___
__

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

[Tzu-ping Chung]

Change by Tzu-ping Chung :


--
nosy: +uranusjr

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31712] subprocess with stderr=subprocess.STDOUT hang

[l4mer]

l4mer  added the comment:

I) Manual test for subprocess32:

janusz@nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd = ["ssh", "root@localhost", "-p", "50494", "whoami"]
>>> buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
>>> print buf
root

>>>
janusz@nc6120:~$ ssh root@localhost -p 50494 -O exit
Exit request sent.
janusz@nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd = ["ssh", "root@localhost", "-p", "50494", "whoami"]
>>> buf = subprocess32.check_output(cmd, stderr=subprocess32.STDOUT)
after 20 seconds
^CTraceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 628, in 
check_output
output, unused_err = process.communicate(timeout=timeout)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 915, in 
communicate
stdout = _eintr_retry_call(self.stdout.read)
  File "/usr/lib/python2.7/dist-packages/subprocess32.py", line 543, in 
_eintr_retry_call
return func(*args)
KeyboardInterrupt
>>>

II) When omit stderr:

janusz@nc6120:~$ ssh root@localhost -p 50494 -O exit
Exit request sent.
janusz@nc6120:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess32
>>> cmd = ["ssh", "root@localhost", "-p", "50494", "whoami"]
>>> buf = subprocess32.check_output(cmd)
>>> print buf
root

>>>

Strace for stderr=None:

mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7071000
close(6)= 0
close(5)= 0
close(4)= 0
ugetrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
close(3)= 0
pipe2([3, 4], O_CLOEXEC)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl64(3, F_GETFL) = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0xb74e3768) = 2728
close(6)= 0
close(4)= 0
brk(0x93d2000)  = 0x93d2000
read(5, "", 5)  = 0
brk(0x93c6000)  = 0x93c6000
close(5)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
_llseek(3, 0, 0xbfe23f90, SEEK_CUR) = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)= 5
read(3, "", 1)  = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2728, si_uid=1000, 
si_status=0, si_utime=6, si_stime=0} ---
close(3)= 0
waitpid(2728, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 2728
rt_sigaction(SIGINT, {SIG_DFL, [], 0}, {0x8183c10, [], 0}, 8) = 0
brk(0x93c4000)  = 0x93c4000
exit_group(0)   = ?
+++ exited with 0 +++

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31712] subprocess with stderr=subprocess.STDOUT hang

[l4mer]

l4mer  added the comment:

Interesting when using faster machine with newer ssh don't see this problem :)

janusz@t560:~$ ssh -V
OpenSSH_7.3p1 Ubuntu-1ubuntu0.1, OpenSSL 1.0.2g  1 Mar 2016

janusz@t560:~$ ssh root@localhost -O exit; strace python test.py

getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
close(3)= 0
pipe2([3, 4], O_CLOEXEC)= 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fcntl(3, F_GETFL)   = 0 (flags O_RDONLY)
pipe2([5, 6], O_CLOEXEC)= 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7fb7ba6fc9d0) = 22284
close(6)= 0
close(4)= 0
brk(0xca73792000)   = 0xca73792000
read(5, "", 5)  = 0
brk(0xca73786000)   = 0xca73786000
close(5)= 0
fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek)
read(3, "root\n", 6)= 5
read(3, "", 1)  = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22284, si_uid=1000, 
si_status=0, si_utime=1, si_stime=0} ---
close(3)= 0
wait4(22284, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 22284
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fb7ba2f1630}, {0xca720ef1a0, 
[], SA_RESTORER, 0x7fb7ba2f1630}, 8) = 0
exit_group(0)   = ?
+++ exited with 0 +++

So, two options here:
- new version of ssh
- faster CPU

Will try to update ssh on the old/slow machine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31718] some methods of uninitialized io.IncrementalNewlineDecoder objects raise SystemError

[Oren Milman]

Change by Oren Milman :


--
keywords: +patch
pull_requests: +3886
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31712] subprocess with stderr=subprocess.STDOUT hang

[Martin Panter]

Martin Panter  added the comment:

Scanning over the Open SSH commits for 7.3p1

https://github.com/openssh/openssh-portable/compare/V_7_2_P2...V_7_3_P1

it looks like this commit

https://github.com/openssh/openssh-portable/commit/d2d6bf864e52af8491a60dd507f85b74361f5da3

may fix your problem. It points to

https://bugzilla.mindrot.org/show_bug.cgi?id=1988

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31718] some methods of uninitialized io.IncrementalNewlineDecoder objects raise SystemError

[Oren Milman]

Oren Milman  added the comment:

With regard to refleaks in __init__() methods, i started looking for similar 
refleaks
in the codebase, and hope to open an issue to fix them soon.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31712] subprocess with stderr=subprocess.STDOUT hang

[l4mer]

l4mer  added the comment:

confirm, OpenSSH_7.3p1 solve the problem.
Thanks for help.

--
resolution:  -> third party
status:  -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31720] msilib.MSIError is spelled MsiError in documentation

[Tzu-ping Chung]

New submission from Tzu-ping Chung :

The title describes it all.

--
assignee: docs@python
components: Documentation
messages: 303877
nosy: docs@python, uranusjr
priority: normal
severity: normal
status: open
title: msilib.MSIError is spelled MsiError in documentation
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31720] msilib.MSIError is spelled MsiError in documentation

[Tzu-ping Chung]

Change by Tzu-ping Chung :


--
keywords: +patch
pull_requests: +3887
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31721] assertion failure in FutureObj_finalize() after setting _log_traceback to True

[Oren Milman]

New submission from Oren Milman :

The following code causes an assertion failure in FutureObj_finalize() (in
Modules/_asynciomodule.c):

import asyncio
asyncio.Future()._log_traceback = True


Maybe we should allow Python code to only set it to False, and raise a
ValueError in case Python code tries to set it to True?

(PR 2050 made _log_traceback writable. Are there any usecases for setting it to
True from Python code?)

--
components: asyncio
messages: 303878
nosy: Oren Milman, yselivanov
priority: normal
severity: normal
status: open
title: assertion failure in FutureObj_finalize() after setting _log_traceback 
to True
type: crash
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31722] _io.IncrementalNewlineDecoder doesn't inherit codecs.IncrementalDecoder

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

It is documented that io.IncrementalNewlineDecoder inherits 
codecs.IncrementalDecoder. And the Python implementation does. But the C 
implementation doesn't.

>>> issubclass(_pyio.IncrementalNewlineDecoder, codecs.IncrementalDecoder)
True
>>> issubclass(_io.IncrementalNewlineDecoder, codecs.IncrementalDecoder)
False
>>> issubclass(io.IncrementalNewlineDecoder, codecs.IncrementalDecoder)
False

--
components: IO, Library (Lib)
messages: 303879
nosy: benjamin.peterson, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: _io.IncrementalNewlineDecoder doesn't inherit codecs.IncrementalDecoder
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31718] some methods of uninitialized io.IncrementalNewlineDecoder objects raise SystemError

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +benjamin.peterson, stutzbach
versions: +Python 2.7, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31722] _io.IncrementalNewlineDecoder doesn't inherit codecs.IncrementalDecoder

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

As a consequence, _io.IncrementalNewlineDecoder doesn't have the error 
attribute.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31165] list_slice() does crash if the list is mutated indirectly by PyList_New()

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +3888

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31165] list_slice() does crash if the list is mutated indirectly by PyList_New()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See a4dd011259fa6f3079bd0efd95b3a136c0e3c190. The commit message:

Tentative fix for a problem that Tim discovered at the last moment,
and reported to python-dev: because we were calling dict_resize() in
PyDict_Next(), and because GC's dict_traverse() uses PyDict_Next(),
and because PyTuple_New() can cause GC, and because dict_items() calls
PyTuple_New(), it was possible for dict_items() to have the dict
resized right under its nose.

The solution is convoluted, and touches several places: keys(),
values(), items(), popitem(), PyDict_Next(), and PyDict_SetItem().

There are two parts to it. First, we no longer call dict_resize() in
PyDict_Next(), which seems to solve the immediate problem.  But then
PyDict_SetItem() must have a different policy about when *it* calls
dict_resize(), because we want to guarantee (e.g. for an algorithm
that Jeremy uses in the compiler) that you can loop over a dict using
PyDict_Next() and make changes to the dict as long as those changes
are only value replacements for existing keys using PyDict_SetItem().
This is done by resizing *after* the insertion instead of before, and
by remembering the size before we insert the item, and if the size is
still the same, we don't bother to even check if we might need to
resize.  An additional detail is that if the dict starts out empty, we
must still resize it before the insertion.

That was the first part. :-)

The second part is to make keys(), values(), items(), and popitem()
safe against side effects on the dict caused by allocations, under the
assumption that if the GC can cause arbitrary Python code to run, it
can cause other threads to run, and it's not inconceivable that our
dict could be resized -- it would be insane to write code that relies
on this, but not all code is sane.

Now, I have this nagging feeling that the loops in lookdict probably
are blissfully assuming that doing a simple key comparison does not
change the dict's size.  This is not necessarily true (the keys could
be class instances after all).  But that's a battle for another day.

We have the same issue with lists. PR 3915 tries to fix it by applying the same 
solution -- calling PyList_New() again if the source container was resized. 
list_slice() no longer can be considered safe, because it uses the size 
calculated before calling PyList_New(). Added _PyList_Copy() for copying the 
list for replacing unsafe PyList_GetSlice(). PyList_SetSlice() is not safe too 
(the PR still not fixes this). The code that uses the combination of 
PyList_GetSlice() and PyList_SetSlice() for safety (like in _asynciomodule.c) 
is not safe. Many code, including most implementations of slicing, should be 
rewritten if we go this way. PR 3915 shows only small example of such changes.

I think than changing the Garbage Collector would be easier.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31720] msilib.MSIError is spelled MsiError in documentation

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3889

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31720] msilib.MSIError is spelled MsiError in documentation

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3890

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31165] list_slice() does crash if the list is mutated indirectly by PyList_New()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I think than changing the Garbage Collector would be easier.

What does "changing" mean exactly?  What will be the effects on normal code?  
How do you know that it will not create new problems that didn't exist before?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31723] refleaks in zipimport when calling zipimporter.__init__() more than once

[Oren Milman]

New submission from Oren Milman :

The following code causes refleaks:
import zipimport
zi = zipimport.zipimporter.__new__(zipimport.zipimporter)
zi.__init__('bar.zip')
zi.__init__('bar.zip')
zi.__init__('bar.zip\\foo')

This is because zipimport_zipimporter___init___impl() (in Modules/zipimport.c)
doesn't decref (if needed) before assigning to `self->files`, `self->archive`
and `self->prefix`.

I would open a PR to fix this soon.

Should i add a test to test_zipimport?
If yes, could you point out some similar refcount test to help me write this
test?

--
components: Extension Modules
messages: 303883
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: refleaks in zipimport when calling zipimporter.__init__() more than once
type: resource usage
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31340] Use VS 2017 compiler for build

[Steve Dower]

Steve Dower  added the comment:

No, but if we need to do 3.6.4 quickly for another reason, let me know and I'll 
make this change.

It only affects people who are trying to share intermediate build files (which 
for MSVC purposes, includes static libraries) between their 3.6.2 and 3.6.3 
builds. Full builds are going to be fine, and incremental builds should detect 
the changed tools and be able to rebuild everything. 

So it's solely cases where people are trying to manage the build around 
distutils rather than letting distutils handle it all that are problematic (and 
hey, both of these are terrible options! This is why we're discussing how to 
get people to just stop depending on distutils). I don't think it's worth 
churning the entire ecosystem just for that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31695] Improve bigmem tests

[Antoine Pitrou]

Antoine Pitrou  added the comment:

+1 to all this :-)

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31720] msilib.MSIError is spelled MsiError in documentation

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:


New changeset 5f396dba1d11356ab18e3bec130596197e741a64 by Mariatta (Miss 
Islington (bot)) in branch '3.6':
bpo-31720: msilib documentation, change MsiError into MSIError (GH-3914) 
(GH-3917)
https://github.com/python/cpython/commit/5f396dba1d11356ab18e3bec130596197e741a64


--
nosy: +Mariatta

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31720] msilib.MSIError is spelled MsiError in documentation

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Thanks!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.4, Python 3.5, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Steve Dower]

Steve Dower  added the comment:

Haven't had a chance to test this, but I suspect our change should depend on 
what happens when a C++ exception is actually unhandled.

In this case, the following sequence has occurred:
* exception is raised
* debug event is raised (if a debugger is attached)
* stack-based handlers get first-chance to ignore the exception
 * there is a stack-based handler that says "let it be raised" and the search 
stops
* vector-based handlers are called
* stack unwind begins, and when the handler is reached it allows execution to 
continue

Unfortunately, I don't think there's going to be any difference between the 
unhandled and handled cases at the point where our handler exists - at worst, 
the OS is going to say that it is "handled" and its handler will kill the 
process. The first chance lookup is actually there to continue execution and 
ignore the exception (possibly after fixing an argument or allocating a new 
page, etc.).

So I think our choices are:
* report no C++/CLR exceptions via faulthandler
* report all C++/CLR exceptions via faulthandler (current behaviour)

I'm inclined towards changing to the first option. The runtime is going to dump 
a more useful message than us if the exception makes it that far, and a C++ 
exception can never be caused by CPython itself.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31701] faulthandler dumps 'Windows fatal exception: code 0xe06d7363'

[Steve Dower]

Steve Dower  added the comment:

Okay, just tested taking out the C++ handler and it goes straight to an error 
report. Not ideal, especially since the error is logged against "python.exe" 
and "ucrtbase.dll" (which is going to make my life harder when reviewing the 
submitted crash reports), but since it can only be caused by user code, it's 
probably better than spamming on every handled exception.

E06D7363 (msc) and E0434352 (CCR) at least should be ignored. I think there's a 
third, but don't remember what it is right now.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25862] TextIOWrapper assertion failure after read() and SEEK_CUR

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
pull_requests: +3891
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31723] refleaks in zipimport when calling zipimporter.__init__() more than once

[Oren Milman]

Change by Oren Milman :


--
keywords: +patch
pull_requests: +3892
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31165] list_slice() does crash if the list is mutated indirectly by PyList_New()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> What does "changing" mean exactly?

I'm not a GC expert. Maybe we should add a global flag that disable calling 
nontrivial destructors and set it in PyObject_GC_New(). The objects with 
nontrivial destructor should be added to the special queue and destroyed in 
"safe" place. There may be a problem with determining the "safe" place. I think 
that any Py_DECREF() is a "safe" place, and the eval loop is a "safe" place.

> What will be the effects on normal code?

I think this shouldn't affect Python code if perform deferred destroying in the 
eval loop. This can affect the execution of extensions if reference loops are 
created in C code. Some objects in loops can live longer that before.

> How do you know that it will not create new problems that didn't exist before?

I don't know. But we can try and see what is the result.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31655] SimpleNamespace accepts non-string keyword names

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 79ba471488b936abda5ba5234b1ea90cbc94cae6 by Serhiy Storchaka in 
branch 'master':
bpo-31655: Validate keyword names in SimpleNamespace constructor. (#3909)
https://github.com/python/cpython/commit/79ba471488b936abda5ba5234b1ea90cbc94cae6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31655] SimpleNamespace accepts non-string keyword names

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3893

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31655] SimpleNamespace accepts non-string keyword names

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset cae6e4775b37c412609d3a0d303c0831ff0012ff by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31655: Validate keyword names in SimpleNamespace constructor. 
(GH-3909) (#3920)
https://github.com/python/cpython/commit/cae6e4775b37c412609d3a0d303c0831ff0012ff


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31655] SimpleNamespace accepts non-string keyword names

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31267] threading.Timer object is affected by changes to system time: Python locks should use a monotonic clock if available

[Thomas Keppler]

Thomas Keppler  added the comment:

Hello Victor,

thank you for your update on this issue.

By looking through the other bug reports you listed, it looks as if measures 
were implemented but never merged. Am I right with this observation? If so, 
will we ever see a switch over to monotonic time?

Thanks for the info :)

--
Best regards
Thomas

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc should use something other than buildbot.python.org

[Zachary Ware]

New submission from Zachary Ware :

With the upgrade to buildbot 0.9, the xmlrpc interface to buildbot.python.org 
is removed, causing test_xmlrpc to fail.  The test should hit a different host, 
possibly on pythontest.net?

--
components: Tests
messages: 303894
nosy: loewis, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_xmlrpc should use something other than buildbot.python.org
versions: Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Zachary Ware]

Change by Zachary Ware :


--
title: test_xmlrpc should use something other than buildbot.python.org -> 
test_xmlrpc_net should use something other than buildbot.python.org

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Zachary Ware]

Change by Zachary Ware :


--
keywords: +patch
pull_requests: +3894
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Zachary Ware]

Change by Zachary Ware :


--
stage: patch review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Zachary Ware]

Zachary Ware  added the comment:


New changeset 73ffd3f2036179ed54591ef0455e5ba5694ae5bd by Zachary Ware in 
branch 'master':
bpo-31724: Skip test_xmlrpc_net (GH-3921)
https://github.com/python/cpython/commit/73ffd3f2036179ed54591ef0455e5ba5694ae5bd


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +3895
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Zachary Ware]

Zachary Ware  added the comment:

This is currently mitigated by some nasty hacks on the buildbot.python.org 
server to avoid breaking tests on every released version of Python 3, but this 
still needs to change.  The test is skipped in master and (soon) 3.6 to 
minimize the damage when the hacks on buildbot.p.o break.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31724] test_xmlrpc_net should use something other than buildbot.python.org

[Zachary Ware]

Zachary Ware  added the comment:


New changeset d13a4e50679c0861971cfae2bb226f35b8bf5142 by Zachary Ware (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31724: Skip test_xmlrpc_net (GH-3922)
https://github.com/python/cpython/commit/d13a4e50679c0861971cfae2bb226f35b8bf5142


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com