STINNER Victor added the comment:
This issue is a duplicate of #11277.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Issue #11760 has been marked as a duplicate of this issue.
--
___
Python tracker
<http://bugs.python.org/issue11277>
___
___
STINNER Victor added the comment:
Here is a nice trace on "PPC Leopard 3.x" thanks to faulthandler + regrtest
timeout (30 minutes):
---
...
[218/354] test_multiprocessing
Thread 0xf0617000:
File "/Users/buildbot/buildarea/3.x.parc-leopard-1/build/L
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue9592>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
I think that the last test_threadsignals failures on PPC Tiger were related to
the new regrtest timeout, and it is now fixed.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
STINNER Victor added the comment:
I wrote the assertion while dump_tracebacks_later() was implemented using
SIGALRM + alarm(timeout). A simple fix for this issue is just to remove the
assertion. But... I'm curious, and I would like to understand.
The problem is on the following
STINNER Victor added the comment:
8da8cd1ba9d9 should fix this issue. Please reopen it if it doesn't solved it.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
STINNER Victor added the comment:
> Hum, I'm not sure that my patch works if the locale encoding is not
> UTF-8: import.c manipulates path in the filesystem encoding, whereas
> PyTokenizer_FindEncodingFilename() expects UTF-8 filename.
Thanks to my work on #3080, the import
Changes by STINNER Victor :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue10785>
___
___
Python-bugs-list
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue7805>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from STINNER Victor :
test_threadsignals hangs on "x86 Tiger 3.x" and "PPC Tiger 3.x":
-
[279/354] test_threadsignals
Thread 0xa000d000:
File
"/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_threadsignals.py",
New submission from STINNER Victor :
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:
regrtest default timeout is now 30 minutes.
I opened specific issues for each failure:
* test_sendall_interrupted() of test_socket: issue #11753
* test_itimer_real() of test_signal: issue #11755
* test_threadsignals: issue #11768
* test_notify() of
STINNER Victor added the comment:
Recent crash on "PPC Tiger 3.x":
[188/354] test_ttk_guionly
Fatal Python error: Segmentation fault
Traceback (most recent call first):
File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/tkinter/ttk.py",
line 47
STINNER Victor added the comment:
ttk_guionly creates a button (ttk.Button()) which calls _load_tile(), which
crashs on: master.tk.eval('package require tile')
Code of the function:
-
def _load_tile(master):
if _REQUIRE_TILE:
import os
STINNER Victor added the comment:
Marc, could you maybe write a new patching taking care of the DST and
maybe also the timezone? It looks like you have a long experience in
timestamps :-)
--
___
Python tracker
<http://bugs.python.org/issue2
STINNER Victor added the comment:
functools_cmp_to_key() doesn't check that the argument is a callable.
>>> table=list(range(3))
>>> table.sort(key=functools.cmp_to_key(3))
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11766>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
title: test_zlib crashes under Snow Leopard buildbot ->
test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD)
___
Python tracker
<http://bugs.python.org/issu
Changes by STINNER Victor :
--
title: test_subprocess failure ->
test_subprocess.test_communicate_timeout_large_ouput failure on select():
negative timeout?
___
Python tracker
<http://bugs.python.org/issu
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue1692335>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from STINNER Victor :
$ ./python
Python 3.3a0 (default:76ed6a061ebe, Apr 5 2011, 12:25:00)
>>> import hashlib, pickle
>>> hash=hashlib.new('md5')
>>> pickle.dumps(hash)
Traceback (most recent call last):
File "", line 1, in
STINNER Victor added the comment:
Oh, I don't know if it is possible to serialize a OpenSSL hash object
(EVP_MD_CTX)...
--
___
Python tracker
<http://bugs.python.org/is
STINNER Victor added the comment:
> 1) A multiprocessing worker can not return (return, not raise!) an
> Exception. (...) raise an error if multiple arguments are required:
> TypeError: ('__init__() takes exactly 2 arguments (1 given)',
> , ())
This problem
STINNER Victor added the comment:
Ok.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11665>
___
___
Pyth
New submission from STINNER Victor :
The creation of a file of 5.25 GB took more than 30 min on "AMD64 Snow Leopard
3.x" buildbot, and so regrtest exited:
-
[ 27/354] test_mmap
Thread 0x7fff70439ca0:
File
"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86
STINNER Victor added the comment:
The test step was interrupted after "38 mins, 45 secs" (including 30 min of
timeout) at the test 27, whereas the previous (success) test step took "46
mins, 55 secs" to execute all (354) tests.
STINNER Victor added the comment:
> I think it is more a question of "is this an easy fix?"
> or would it require extensive changes to support unicode properly.
First of all, the question is: who would like to develop it. You can vote for
an issue, but it doesn't change
STINNER Victor added the comment:
> Anyway, try to use Python everywhere in Python 2 is a waste of time.
Oh... I mean "use Unicode in Python 2"
--
___
Python tracker
<http://bugs.pytho
STINNER Victor added the comment:
Another test_multiprocessing failure (30 min timeout) on x86 XP-4 3.x:
--
[125/354] test_multiprocessing
Thread 0x0e5c:
File
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\threading.py", line
235 in wait
File
Changes by STINNER Victor :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11771>
___
___
Python-bugs-
STINNER Victor added the comment:
The failure occurs also on Leopard:
--
[159/354] test_threadsignals
Thread 0x7fff7080f700:
File
"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_threadsignals.py",
line 53 in test_signals
Fil
New submission from STINNER Victor :
I added recently a --timeout option to regrtest.py: dump the traceback of all
threads and exit if a test takes more than TIMEOUT seconds (issue #11727). But
my implementation was not correct: the timeout is applied on the whole file,
not on a single
STINNER Victor added the comment:
You may also patch poll_poll().
--
___
Python tracker
<http://bugs.python.org/issue11757>
___
___
Python-bugs-list mailin
STINNER Victor added the comment:
I forgot to patch some calls to runtest(): new patch.
--
Added file: http://bugs.python.org/file21575/regrtest_timeout-2.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21573/regrtest_timeout.patch
___
Python tracker
<http://bugs.python.org/issue11800>
___
___
Python-bug
STINNER Victor added the comment:
jseutter reproduced it after 112 and 49 runs on Snow Leopard using "regrtest.py
-F -v --timeout=60 test_threadsignals" command:
---
[ 49] test_threadsignals
test_interrupted_timed_acquire (test.test_threadsignals.ThreadSigna
STINNER Victor added the comment:
Oh, the traceback only contains one thread, so send_signals() thread was not
created or failed very quickly (before its first print instruction).
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
I would like a timeout per function call because some files contain many slow
tests: the duration of a file depends on the number of tests. Imagine that all
functions takes 1 second: a file with 200 functions takes 200 seconds, whereas
a file with 1 test
STINNER Victor added the comment:
> Still I don't see the point. Is a 60 minutes timeout too long?
If regrtest timeout is too close to the buildbot timeout, we may not get the
traceback if the blocking test is the last test.
I don't know yet if we will get false positive with a
STINNER Victor added the comment:
Le vendredi 08 avril 2011 à 05:34 +, Charles-Francois Natali a
écrit :
> Charles-Francois Natali added the comment:
>
> > You may also patch poll_poll().
> >
>
> Poll accepts negative timeout values, since it's the only way
STINNER Victor added the comment:
I fixed a bug in _communicate_with_poll(): raise an error if the endtime-time()
is negative. If poll() is called with a negative timeout, it blocks until it
gets an event.
New changeset 3664fc29e867 by Victor Stinner in branch 'default':
Is
STINNER Victor added the comment:
Simplify the test and set the default timeout to 15 min.
--
Added file: http://bugs.python.org/file21582/regrtest_timeout-3.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21575/regrtest_timeout-2.patch
___
Python tracker
<http://bugs.python.org/issue11800>
___
___
Pytho
STINNER Victor added the comment:
With the current implementation of faulthandler.dump_tracebacks_later(), use a
timeout per function means create a new thread for each function (the thread is
interrupted and exits when the test is done).
Quick benchmark with test_io on Linux (lowest "
STINNER Victor added the comment:
I did a similar test on Windows: test_io takes ~19.1 sec with and without
timeout. If I look closer, the timeout overhead (call a thread per function
call) is 112 µs per function call. The average duration of a test is 48 ms
(47,750 µs), so the overhead is
STINNER Victor added the comment:
Le vendredi 08 avril 2011 à 17:31 +, Antoine Pitrou a écrit :
> Antoine Pitrou added the comment:
>
> > I did a similar test on Windows: test_io takes ~19.1 sec with and
> > without timeout.
>
> You may want to test
STINNER Victor added the comment:
I emulated Mac OS X behaviour on Linux by hacking my_fgets(): do { p=NULL;
errno = EINTR; }, only after the first call to fgets(). Without the patch,
Python does exit immediatly. With the patch, Python doesn't exit.
I applied neologix's patch t
STINNER Victor added the comment:
Attached patch disables regrtest.py timeout if
faulthandler.dump_tracebacks_later() is missing. It prints a warning at
startup, and an error if --timeout option is used.
--
keywords: +patch
Added file: http://bugs.python.org/file21613/timeout.patch
STINNER Victor added the comment:
> (Victor, please don't file many bugs in a single issue!)
I thought that these issues were the same.
Victor
--
___
Python tracker
<http://bugs.python.or
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11840>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by STINNER Victor :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11186>
___
___
Python-bugs-list
STINNER Victor added the comment:
Here is a patch: Antoine, would you like to review it?
--
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file21636/rlock_release_save.patch
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
One year after opening the issue, I don't have any real use case. And there are
technical issues to implement this feature, so I prefer just to close this
issue. Reopen it if you really want it, but please give an use case ;-)
--
resolution: -&
STINNER Victor added the comment:
I did not see this failure since one year. flox saw it 7 months ago.
I close this issue because I think that it is fixed. Reopen it if the issue was
not fixed.
--
resolution: -> out of date
status: open ->
STINNER Victor added the comment:
I developed the faulthandler module to get more information after a timeout. I
close this issue: I already opened more specific issues with more information.
--
resolution: -> invalid
status: open ->
STINNER Victor added the comment:
There are no more ARM buildbots, so let's close this issue.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python
STINNER Victor added the comment:
I don't understand why this issue is still open, so let's close it.
--
status: open -> closed
___
Python tracker
<http://bugs.pyth
Changes by STINNER Victor :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11825>
___
___
Python-bugs-list
STINNER Victor added the comment:
Antoine changed regrtest default timeout to 60 minutes. It should workaround
test_mmap timeout, so can we close this issue?
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
> Thanks Freek - we're actually discussing some stuff like this
> in issue9205 as well
I'm unable to see the relation between the issue #9205 and the point (3) of
this issue (RuntimeError: maximum recursion depth exceeded while calling
Changes by STINNER Victor :
--
nosy: -haypo
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
This issue remembers me the issue #6612 (failure if the current directory was
removed): the fix was to ignore os.getcwd().
Attached patch ignores os.path.expanduser() error (KeyError) and keeps ~ in the
path. Example without HOME var and with an non existent
Changes by STINNER Victor :
--
keywords: +patch
Added file: http://bugs.python.org/file21639/sysconfig_getuserbase.patch
___
Python tracker
<http://bugs.python.org/issue10
Changes by STINNER Victor :
Removed file: http://bugs.python.org/file21639/sysconfig_getuserbase.patch
___
Python tracker
<http://bugs.python.org/issue10496>
___
___
Pytho
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21640/sysconfig_getuserbase.patch
___
Python tracker
<http://bugs.python.org/issue10496>
___
___
Pytho
STINNER Victor added the comment:
print(repr(json.loads(json.dumps({u"my_key": u'\uda00'}))['my_key'])):
- displays u'\uda00' in Python 2.7, 3.2 and 3.3
- raises a ValueError('Invalid \u escape: ...') on loads() in Python 2.6
- raises a V
STINNER Victor added the comment:
> If a user unknowingly creates such a module with an unencodable
> filename, will they understand why pydoc does not display it?
It is really a bad idea to choose an *undecodable* name for a module. You will
not be able to write its name using "
STINNER Victor added the comment:
> ... which does not give the same result in UCS-2 and UCS-4 builds.
> As a result, the pyc file is not portable across those builds.
Since Python 3.2, the pyc filename contains a tag (u) to indicate wide build
(sys.maxunicode==0x10), instead of
STINNER Victor added the comment:
Because the patch is simple (just add a try/except), I think that it doesn't
matter if only few people use users without entry in /etc/passwd and we should
fix this issue.
--
___
Python tracker
STINNER Victor added the comment:
I tested issue11397_py32.patch:
- you should use os.fsencode(sep) instead of sep.encode()
- os.path.realpath('../'*10) raises IndexError('pop from empty list') instead
of giving '/'
--
___
STINNER Victor added the comment:
This issue is a duplicate of #1726687 which is already fixed in Python 2.7 by
7a89f4a73d1a (Feb 15 2011): it will be part of 2.7.2.
Only security vulnerabilities are fixed in Python 2.6, so I change the version
field to 2.7 only.
--
nosy: +haypo
Changes by STINNER Victor :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11850>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11851>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from STINNER Victor :
test_interrupted_write_text() of test_io failed of Python 3.3 on FreeBSD 7.2:
---
[250/354] test_io
Exception in thread Thread-1316:
Traceback (most recent call last):
File "/usr/home/db3l/buildarea/3.x.
STINNER Victor added the comment:
I already read somewhere that on FreeBSD, any thread can receive a signal, not
only the main thread. I suppose that it should be the same on Linux, but Linux
tries maybe to send a signal to the main thread if the main thread and other
threads are calling a
STINNER Victor added the comment:
One solution to fix this problem is to use pthread_sigmask() on the _read()
thread to not handle SIGARLM. For example, the faulthandler uses the following
code to not handle any thread in its timeout thread:
#ifdef HAVE_PTHREAD_H
sigset_t set;
/* we
STINNER Victor added the comment:
Let's close this issue. I will reopen it if a timeout of 60 min was not the
right choice to workaround this failure.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://b
STINNER Victor added the comment:
Oh, I reproduced the bug.
[3021] test_threadsignals
test_signals (test.test_threadsignals.ThreadSignals) ... test_signals: acquire
lock (thread -1610559488)
test_signals: wait lock (thread -1610559488)
send_signals: enter (thread
STINNER Victor added the comment:
> The main thread was waiting test_signals() lock (signalled_all)
> while it is was interrupted by a signal. The signal handler calls
> Py_AddPendingCall() which blocks on acquiring "pending_lock".
Oh, the main thread receives SIGUSR1:
STINNER Victor added the comment:
It looks like pthread_mutex_lock() and pthread_mutex_unlock() are not reentrant
on some platforms (in some implementations of the pthread API).
Antoine: if I understand correctly your patch, if we have a pending signal, all
next signals will be simply
STINNER Victor added the comment:
> pthread_sigmask() can be used to avoid reentrant call,
> but it has no effect on the second case: "signal_handler()
> called twice at the same time in two different threads".
Same problem if we use sa_mask field of sigaction() (e
STINNER Victor added the comment:
> I don't think so, please re-read.
Oh, I thought that Py_AddPendingCall() was used to store the pending signal.
But no, it asks Python main loop to check which signal has been trigerred, and
we can only do it once for all signals.
Attached patch sh
Changes by STINNER Victor :
--
title: test_signals() of test_threadsignals failure on Mac OS X ->
signal_handler() is not reentrant: deadlock in Py_AddPendingCall()
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
Le lundi 18 avril 2011 à 10:40 +, STINNER Victor a écrit :
> Attached patch should fix this issue:
>
> - signal_handler() and PyErr_SetInterrupt() only call Py_AddPendingCall() on
> the first signal (if is_tripped is zero): it should fix the
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21703/signal_versionadded.patch
___
Python tracker
<http://bugs.python.org/issue11768>
___
___
Pytho
Changes by STINNER Victor :
--
title: test_signals() of test_threadsignals failure on Mac OS X ->
signal_handler() is not reentrant: deadlock in Py_AddPendingCall()
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
The deadlock is fixed. Reopen the issue if you still see test_threadsignals
hang on a buildbot.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by STINNER Victor :
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue8407>
___
___
Python-bugs-list mailing list
Unsubscribe:
STINNER Victor added the comment:
sigprocmask or (better) pthread_sigmask is required to fix #11859 bug.
---
Python has a test for "broken pthread_sigmask". Extract of configure.in:
AC_MSG_CHECKING(if PTHREAD_SCOPE_SYSTEM is supported)
AC_CACHE_VAL(ac_cv_pthread_system
New submission from STINNER Victor :
test_3_join_in_forked_from_thread() of test_threading failed on "x86 Ubuntu
Shared 3.x" buildbot:
---
[201/354] test_threading
[41179 refs]
[40407 refs]
[40407 refs]
[40407 refs]
Timeout (1:00:00)!
Thread 0x404218
STINNER Victor added the comment:
Hum, it does still fail with a timeout of 1 hour:
---
[ 41/354] test_mmap
Timeout (1:00:00)!
Thread 0x7fff70439ca0:
File
"/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_mmap.py",
STINNER Victor added the comment:
A timeout of 60 minutes looks to be fine. Today I debuged a thread+signal issue
which gave me an headache, so I prefer to close this issue: only add create
thread per file, and not a thread per function.
--
resolution: -> wont fix
status: o
New submission from STINNER Victor :
While trying to reproduce issue #11870 using "gdb -args ./python
Lib/test/regrtest.py -F -v --timeout=600 test_threading", I had the following
error on Linux:
--
test_default_timeout (test.test_threading.BarrierTests) .
STINNER Victor added the comment:
We can use the following function to check if the filesystem does support
sparse files:
def support_sparse_file(directory):
import tempfile
with tempfile.NamedTemporaryFile(dir=directory) as tmpfile:
# Create a file with a size of 1 byte but
STINNER Victor added the comment:
Timing on the x86 Tiger buildbot: "time ./python.exe -m test -v -u largefile
test_mmap" gives approx 5 minutes. The buildbot is a Mac mini, Intel Core Duo
1.8 GHz, 2 GB of memory, Mac OS X 10.4.10, HD: 232 GB (182 GB available) WDC
WD2500BEVT-00A2
New submission from STINNER Victor :
Trace:
--
[ 30/354] test_compileall
test test_compileall failed -- Traceback (most recent call last):
File
"/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib
STINNER Victor added the comment:
> “If a signal is delivered to a thread waiting for a condition variable,
> upon return from the signal handler the thread resumes waiting for the
> condition
> variable as if it was not interrupted, or it shall return zero due to spuri
Changes by STINNER Victor :
Added file: http://bugs.python.org/file21714/pthread_cond_timedwait_signal.c
___
Python tracker
<http://bugs.python.org/issue11223>
___
___
New submission from STINNER Victor :
Python/thread.c contains the following messages:
#ifdef SGI_THREADS
#error SGI Irix threads are now unsupported, and code will be removed in 3.3.
#include "thread_sgi.h"
#endif
#ifdef SUN_LWP
#error SunOS lightweight processes are now unsupported
2801 - 2900 of 35284 matches
Mail list logo
