STINNER Victor added the comment:
Cool, someone uses my PyErr_WarnFormat() function! :-) I didn't know that NULL
can be used for the category: I would prefer an explicit PyExc_RuntimeWarning
to not have to read the source of PyErr_WarnFormat() or its document
STINNER Victor added the comment:
Repository URL is incorrect (missing http:/ prefix). The commit:
http://hg.python.org/sandbox/guido/rev/dd852a0f92d6
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
The patch has no test. You may read our new "Python Developer’s Guide" for new
contributors:
http://docs.python.org/devguide/runtests.html#writing
--
___
Python tracker
<http://bugs.python.o
STINNER Victor added the comment:
c6a4d267fe88.diff: This patch doesn't explain why other scheme are not allowed.
I like Guido's comment:
# For security reasons we do not allow redirects to protocols
# other than HTTP or HTTPS.
--
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11663>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
In the following example, if I kill the child process, the parent is immediatly
done:
---
from os import getpid
from time import sleep
from multiprocessing import Process
def f(sec):
print("child %s: wait %s seconds" % (getpid(), sec))
slee
STINNER Victor added the comment:
> For fatal errors, you needn't be async-safe, so the fatal error code
> could read fileno(stderr) and give it to the traceback printing code.
My last patch for issue #8863 does exactly that:
##
void
Py_FatalError(cons
STINNER Victor added the comment:
In the following example, the parent doesn't react when the child process is
killed:
-
from os import getpid
from time import sleep, time
from multiprocessing import Pool
def f(sec):
print("child %s: wait %s seconds" % (getpid(), sec)
Changes by STINNER Victor :
--
title: concurrent.futures (or multiprocessing?) doesn't detect killed processes
-> multiprocessing (and concurrent.futures) doesn't detect killed processes
___
Python tracker
<http://bugs.pytho
STINNER Victor added the comment:
It's possible to stop the parent with a CTRL+c, and so here is the trace of
blocking function:
$ ./python y.py
parent 26706: wait child
child 26707: wait 60 seconds
^CProcess PoolWorker-2:
Traceback (most recent call last):
File "y.py&quo
STINNER Victor added the comment:
Why do you remove NTColor from globals *after* creating it? The assertion looks
useless, or are you testing that globals().pop() works as expected?
tmp = namedtuple('NTColor', 'red green blue')
globals().pop('NTColor', None)
STINNER Victor added the comment:
If I read correctly '(<(?:(?:[^<>]*)|(?:"[^"]*"))*>)', it is something like
(A*|B)*. Regex like (A*)* is *very* slow. It can easily be optimized to A*. Or
for (A*|B)* => (A|B)*.
So '(<(?
STINNER Victor added the comment:
My stronger argument was that %.100s was never supported. I am wrong: Python 2
is only to truncate strings in PyErr_Format() (PyString_FromFormatV() supports
precision for %s format). As I am the only one wanting to changing that, and I
don't hav
Changes by STINNER Victor :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10833>
___
___
Python-bugs-
STINNER Victor added the comment:
I closed #10833 as invalid, because it is a regression of Python 3.
PyErr_String() uses PyString_FromFormatV() in Python 2, which supports
precision for %s, whereas it uses PyUnicode_FromFormatV() in Python 3, which
never supported precision for %s
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11321>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
Le vendredi 25 mars 2011 à 00:54 +, David-Sarah Hopwood a écrit :
> David-Sarah Hopwood added the comment:
>
> I wrote:
> $ python3 -c 'import sys; sys.stdout.write("foo");
> sys.stdout.buffer.write(b"bar"); sys.std
STINNER Victor added the comment:
Let's try the "Remote hg repo" feature.
--
hgrepos: +8
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Changes by STINNER Victor :
--
keywords: +patch
Added file: http://bugs.python.org/file21393/ec274420e9e2.diff
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
Ok, here is a full patch tested on Linux and Windows:
- Add faulthandler module (code, doc, tests) as a builtin module
- Add "-X faulthandler=1" command line option and PYTHONFAULTHANDLER=1 en var
to enable the fault handler at star
STINNER Victor added the comment:
(Reminder for me: add something to Doc/whatsnew/3.3.rst and Misc/NEWS)
--
___
Python tracker
<http://bugs.python.org/issue11
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21403/174bc8c03e9d.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21393/ec274420e9e2.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
STINNER Victor added the comment:
I updated the (Hg repo and the) patch to fix all Antoine's remarks.
--
___
Python tracker
<http://bugs.python.org/is
STINNER Victor added the comment:
I don't know if it is important to document that some functions keep an
internal reference to the file argument. For example, I wrote "It keeps a
reference to file: use disable() to clear this reference." in
faulthandler.enable() docum
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21403/174bc8c03e9d.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21404/605422430234.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
STINNER Victor added the comment:
New patch 605422430234.diff:
- Remove test_refcount(), it changed faulthandler internal state, and so it
was no more possible to use faulthandler in regrtest.py
- Use "#ifdef HAVE_ALARM" to decide if dump_traceback_later() is available,
instead
STINNER Victor added the comment:
Can we use FD_CLOEXEC to archive this goal? Example: open all files with
FD_CLOEXEC set and don't close explicitly files on fork. preexec_fn will get
access to the files, but the problem is exec(), not preexec_fn.
I suppose that it will slow down pro
STINNER Victor added the comment:
regrtest_timeout.patch: add --timeout option to regrtest.py to display the
traceback and then exit if a test takes more than TIMEOUT seconds. It adds also
a check on the subprocess exit code (regrtest.py -j): raise a exception if it
is different than zero
STINNER Victor added the comment:
> I like the approach suggested by Gregory in issue11284 (msg129912) - if we are
> sure the program is not multithreaded, get the list of fds before forking, and
> use that; otherwise, do it the slow way.
A signal handler can also opens
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21467/c684b1e59aaa.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21404/605422430234.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
STINNER Victor added the comment:
I regenerated the patch.
Last changes:
- I merged Antoine's new implementation of
faulthandler.dump_backtraces_later() using a thread
- dump_backtraces_later() has a new exit option: if exit=True, call _exit()
- disable (remove) register() and unreg
STINNER Victor added the comment:
Remainder for me: the patch contains some whitespace changes in Makefile.pre.in
and Setup.dist.
dump_traceback(), enable(), dump_tracebacks_later(), register() flush the input
file. It is not said in the doc. Should it be documented? For enable
STINNER Victor added the comment:
> > - speed up the test: because dump_backtraces_later() has now a
> > subsecond resolution, we can use sleep of 50 ms instead of 1 sec
>
> This is too short, there may be random failures on some slow buildbots.
> IMO, 0.5s is the min
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21470/a979bb83a94b.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21467/c684b1e59aaa.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
STINNER Victor added the comment:
> faulthandler_fatal_error() calls the previous signal handler
> using raise(signum)
It doesn't work as expected on Windows: Windows doesn't call its own signal
handler anymore. Use the previous code (only on Windows).
I also added a test fo
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21474/4adbea7c832e.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21470/a979bb83a94b.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21476/f5a11df83d98.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21474/4adbea7c832e.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
STINNER Victor added the comment:
> My TODO list is empty (the last item was "fix register() to be signal
> safe") so I think that the patch is ready to be commited.
As I wrote, I did some tests on FreeBSD, found bugs and fixed them. I also
fixed the weird behaviour if the use
STINNER Victor added the comment:
I merged the faulthandler branch into the default branch. I removed __version__
field: the Python version should be enough. I also fixed an infinite loop
raised by test_capi.
test_faulthandler pass on Solaris and OpenIndiana, but it fails on PPC
STINNER Victor added the comment:
http://hg.python.org/features/faulthandler/rev/0943ef33495a should fix
test_faulthandler to support SIGBUS on reading from NULL. But it doesn't fix
the failure on SIGFPE yet. I'm running the buildbot to check if it's
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21483/d4902114f720.diff
___
Python tracker
<http://bugs.python.org/issue11393>
___
___
Python-bug
STINNER Victor added the comment:
First failure: AMD64 Gentoo Wide 3.x.
http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/1363/
[1/1] test_faulthandler
test test_faulthandler failed -- Traceback (most recent call last):
File
"/home/buildbot/builda
STINNER Victor added the comment:
test_faulthandler failed also on AMD64 OpenIndiana 3.x: regrtest.py (only
executing test_faulthandler) was killed after 11 min 20 sec.
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
I disabled test_stack_overflow because the test fails on AMD64 Gentoo Wide 3.x,
and maybe other buildbots (AMD64 OpenIndiana 3.x?). I fear that the test uses a
lot of CPU, memory and/or swap.
--
___
Python tracker
STINNER Victor added the comment:
stack_overflow.patch should fix AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana 3.x
failures. I schedule a test on their custom slaves, but these buildbots are
still running test_faulthandler on their 3.x slaves. I interrupted the test,
but it doesn't
STINNER Victor added the comment:
test_logging.test_no_kwargs fails on AMD64 Snow Leopard 2 3.x, x86 Ubuntu
Shared 3.x, sparc solaris10 gcc 3.x, AMD64 Leopard 3.x, x86 XP-4 3.x, x86
Windows7 3.x, x86 Tiger 3.x, PPC Tiger 3.x, ... I disabled the test because it
became difficult to see new
New submission from STINNER Victor :
linecache document doesn't tell that the module reads the #coding:xxx cookie to
get the encoding of the Python file. linecache reads this cookie since 41665
(May 09 2007).
"The linecache module allows one to get any line from any file, ..."
STINNER Victor added the comment:
test_faulthandler blocked AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana 3.x
buildbots because of the stack overflow test.
> New changeset e289b64f355d by Victor Stinner in branch 'default':
> Issue #11393: limit stack overflow test
New submission from STINNER Victor :
I would be nice to add a timeout option to regrtest.py to be able to dump the
traceback after TIMEOUT seconds and also exit the process. It would help
debugging timeout issues (e.g. test_multiprocessing ), but also protect
buildbots against evil (long
STINNER Victor added the comment:
I opened #11727 for the patch on regrtest.py. All buildbots look happy (no more
failure on test_faulthandler), so let's close this issue.
--
resolution: -> fixed
status: open -> closed
___
Python tra
STINNER Victor added the comment:
This issue is a duplicate of #9205.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Issue #11663 has been marked as a duplicate.
--
nosy: +bquinlan, haypo, pitrou
___
Python tracker
<http://bugs.python.org/issue9
STINNER Victor added the comment:
I created a new Mercurial repository to test this issue:
features/regrtest_timeout.
Let's try it with a timeout of 5 minutes on:
- "x86 Tiger custom" to learn more about test_threadsignals timeout (1 hour)
=> issue #11223
- "x86 Fr
STINNER Victor added the comment:
Try the branch on "PPC Leopard 3.x" (test_subprocess timeout):
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%20custom/builds/6
--
___
Python tracker
<http://bugs.python.o
STINNER Victor added the comment:
>> "x86 Tiger custom" to learn more about test_threadsignals timeout
>> (1 hour)
>
> Please read the comments. There is no timeout anymore.
The last build failed with:
---
...
[213/354] test_plistlib
[214/354] test_minidom
STINNER Victor added the comment:
I ran the full test suite on "x86 Tiger custom" on my features/regrtest_timeout
repository: no failure (test_threadsignals failure was not reproduced).
On "PPC Leopard custom", the test suite was interrupted (timeout) on
test_io.test_bas
STINNER Victor added the comment:
Result on "x86 FreeBSD 7.2 custom":
...
[148/354] test_fileinput
[149/354] test_subprocess
[36645 refs]
[36645 refs]
...
[36647 refs]
[44034 refs]
Current thread 0x28401040:
File
"/usr/home/db3l/buildarea/custom.bolen-fre
STINNER Victor added the comment:
test_subprocess.test_leaking_fds_on_error takes more than 5 minutes on x86
FreeBSD 7.2 build slave! This tests creates 1,024 subprocesses, and subprocess
has to close 655,000 file descriptors just to create on child process (whereas
there are only something
STINNER Victor added the comment:
test_subprocess.test_leaking_fds_on_error takes more than 5 minutes on x86
FreeBSD 7.2 build slave! This tests creates 1,024 subprocesses, and subprocess
has to close 655,000 file descriptors just to create on child process (whereas
there are only something
STINNER Victor added the comment:
Same issue on PPC Leopard custom:
[224/354] test_faulthandler
test test_faulthandler failed -- Traceback (most recent call last):
File
"/Users/buildbot/buildarea/custom.parc-leopard-1/build/Lib/test/test_faulthandler.py",
li
STINNER Victor added the comment:
Patch commited into 3.3 (bdc946dc512a, 0f3dbf93ac06). I opened a thread on
python-dev to decide if we turn this on by default on buildbots.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
STINNER Victor added the comment:
Other failures on "x86 XP-4 3.x":
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/4308
==
FAIL: test_dump_tracebacks_later (test.test_faulthandler.FaultHa
STINNER Victor added the comment:
Cool, 69f58be4688a fixed all failures (all related to dump_backtraces_later())
on "x86 XP-4 3.x". So "PPC Leopard" should also be fixed.
--
___
Python tracker
<http://bug
STINNER Victor added the comment:
Ah yes, I have also issues with the Windows fault handler (the popup). I
disabled this popup manually in my Windows XP box.
Instead of skipping the test, I prefer to disable temporary the popup by
setting the right registry key (and then restore the previous
STINNER Victor added the comment:
Ubuntu has also a fault handler: Apport.
https://wiki.ubuntu.com/Apport
Fedora has abrt.
https://fedorahosted.org/abrt/wiki
http://fedoraproject.org/wiki/Features/ABRT
If we should to disable the Windows fault handler, we may also disable these
tools
STINNER Victor added the comment:
It would be interesting to have Counter.elements_count() if it has a complexity
of O(1): if the collections maintains a total (in a private attribute).
Otherwise, I think that sum(c.values()) is enough and can be documented as an
example in the Counter doc
STINNER Victor added the comment:
The last commits fixed test_faulthandler on FreeBSD, there are no more
faulthandler bugs. Close this issue gain.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.p
STINNER Victor added the comment:
Great! The timeout works:
-
...
[ 25/354] test_threadsignals
Thread 0xa000ed88:
File
"/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_threadsignals.py",
line 46 in test_signals
File "
New submission from STINNER Victor :
Thanks to the new faulthandler module (#11393) and regrtest timeout (#11727,
timeout of 15 minutes), I finally found why test_threadsignals hangs on PPC
Tiger 3.x:
-
...
[ 25/354] test_threadsignals
Thread 0xa000ed88
STINNER Victor added the comment:
The trace is supposed to contain the traceback of all threads, and I see only
one thread. So I suppose that send_signals() thread has exited. I don't know if
it raises an exception or was interrupted before calling
signalled_all.re
STINNER Victor added the comment:
Failures on the default branch with a timeout of 15 minutes:
- test_io on "x86 FreeBSD 3.x"
- test_signal on "x86 FreeBSD 7.2 3.x"
- test_stdin_none on "sparc solaris10 gcc 3.x"
I think that the tests failed because the buil
STINNER Victor added the comment:
python -c "import loggingTest" calls PyRun_SimpleStringFlags(). python
import_loggingTest.py (import_loggingTest.py just contains "import
loggingTest") calls PyRun_SimpleFileExFlags(). Both functions calls
PyErr_Print() on error.
An
STINNER Victor added the comment:
(oh, "sparc solaris10 gcc 3.x" failed on test_subprocess, test_stdin_none is
the function, not the file)
With a timeout of 30 minutes:
- "sparc solaris10 gcc 3.x" doesn't fail anymore.
- "x86 FreeBSD 3.x" st
STINNER Victor added the comment:
Because the timeout was 30 minutes, we missed where test_ssl hangs on "x86
Windows7 3.x":
--
...
[259/354] test_filecmp
[260/354] test_ssl
command timed out: 1200 seconds without output, killing pid 3012
SIGKILL failed to kill process
STINNER Victor added the comment:
For test_subprocess timeout, see also:
http://bugs.python.org/issue8429#msg103368
For test_io timeout, see also: issue #8431
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
Timeout of 15 minutes on "x86 XP-4 3.x":
...
[334/354] test_threading
Thread 0x024c:
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line
235 in wait
File
"D:\cyg
STINNER Victor added the comment:
I think that it is a duplicate of #8070.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Issue #11730 has been marked as duplicate.
--
___
Python tracker
<http://bugs.python.org/issue8070>
___
___
Python-bugs-list m
New submission from STINNER Victor :
I added a timeout of 30 minutes to regrtest. On "x86 FreeBSD 7.2 3.x" and "x86
FreeBSD 3.x" buildbot, test_sendall_interrupted() of test_socket does timeout
after 30 minutes:
--
...
[201/354] test_socket
Thread 0x28401040:
F
New submission from STINNER Victor :
test_itimer_real() of test_signal hang 30 minutes on FreeBSD "x86 FreeBSD 3.x"
and "x86 FreeBSD 7.2 3.x" buildbots. Example:
...
[ 95/354] test_signal
Thread 0x28401040:
File
"/usr/home/db3l/buildarea
STINNER Victor added the comment:
Ok, this issue is completly related to regrtest.py timeout (issue #11727):
test_signal with regrtest.py timeout disabled.
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
As issue #11755, this issue is a regression introduced by regrtest timeout
(issue #11727): test_socket doesn't fail without regrtest timeout.
--
___
Python tracker
<http://bugs.python.org/is
STINNER Victor added the comment:
Duplicate of #11753.
--
resolution: -> duplicate
___
Python tracker
<http://bugs.python.org/issue11755>
___
___
Python-
Changes by STINNER Victor :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11755>
___
___
Python-bugs-list mailing list
Unsubscri
STINNER Victor added the comment:
Issue #11755 (test_itimer_real() of test_signal hang on FreeBSD) has been
marked as a duplicate of this issue.
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
The problem is that faulthandler's thread (faulthandler_thread) receives the
SIGALRM signal: the signal interrupts sem_timedwait() which returns EINTR.
PyThread_acquire_lock_timed() retries sem_timedwait() and so the other thread
executing sendall() i
STINNER Victor added the comment:
May be related to #11753.
--
___
Python tracker
<http://bugs.python.org/issue11738>
___
___
Python-bugs-list mailing list
Unsub
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11757>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
test_socket and test_signal succeed on "x86 FreeBSD custom":
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%20custom/builds/4
(there are other issues, but there are not related)
I pushed the fix in Python 3.3 (eb
New submission from STINNER Victor :
Trace:
...
[ 79/354] test_time
[ 80/354] test_zlib
Fatal Python error: Bus error
Traceback (most recent call first):
File
"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_zlib.py",
line 85 in test_
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue6895>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
Another failure on test_zlib on the same buildbot: build 30
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/30/steps/test/logs/stdio
--
I already noticed some failures on test_mmap: build 8, 25 and 36
http://www.python.org
STINNER Victor added the comment:
test_zlib failure is on zlib.crc32(mmap.mmap(...)) with a mapping bigger than 4
GB:
--
# Issue #10276 - check that inputs >=4GB are handled correctly.
class ChecksumBigBufferTestCase(unittest.TestCase):
def setUp(self):
w
STINNER Victor added the comment:
This issue is not dead: test_zlib failed twice on "AMD64 Snow Leopard 3.x"
buildbot: build 30 (024967cdc2f0e850f0b338e7593a12d965017a6a, Mar 31 01:40:00
2011) and 44 (ebc03d7e711052c0b196aacdbec6778c0a6d5c0c, Apr 4 10:11:20 2011).
Build 44 has a
2701 - 2800 of 35284 matches
Mail list logo
