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
STINNER Victor added the comment:
Oh, the file contains also a reference to a missing file:
#ifdef PLAN9_THREADS
#include "thread_plan9.h"
#endif
But I don't see where PLAN9_THREADS is defined.
--
___
Python tracker
<http
STINNER Victor added the comment:
The problem is that I don't know how to check in test_threadsignals which
thread implementation is used in Python. It would be nice to have some
functions providing such information in the sys or sysconfig module, maybe
something like sys.float_info.
STINNER Victor added the comment:
@sdaoden: This issue has a lot of patches, can you remove old patches?
--
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
threading_info.patch:
- Add thread._info() function -> dict with 'name' and 'use_semaphores'
(pthread only) keys
- Skip test_lock_acquire_interruption() and test_rlock_acquire_interruption()
if Python uses pthread without semaphores
STINNER Victor added the comment:
11277.3.diff: this patch looks correct (I'm unable to test it), but can you add
a sentence in mmap doc to explain that mmap.mmap() does flush the file on Mac
OS X and VMS?
--
___
Python tracker
Changes by STINNER Victor :
--
title: test_zlib.test_big_buffer crashes under BSD (Mac OS X and FreeBSD) ->
Crash with mmap and sparse files on Mac OS X
___
Python tracker
<http://bugs.python.org/issu
STINNER Victor added the comment:
Oh, fcntl has already a F_FULLFSYNC constant, so we can use like
fcntl.fcntl(fd, fcntl.F_FULLFSYNC) in Python.
> can you add a sentence in mmap doc to explain that mmap.mmap()
> does flush the file on Mac OS X and VMS?
Hum, it does flush the file
STINNER Victor added the comment:
Oh, and can you add a comment explaining why F_FULLFSYNC is needed on Mac OS X
in your patch? (If I understood correctly, it is needed to avoid crash with
sparse files).
--
___
Python tracker
<h
STINNER Victor added the comment:
> (My last reply-mail changed the title. Fixing.)
Yeah, it's a common problem if you use the email interface :-/
--
___
Python tracker
<http://bugs.python.org
STINNER Victor added the comment:
Oh, this is a duplicate of #11863.
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
STINNER Victor added the comment:
Issue #11876 has been marked as a duplicate of this issue.
--
nosy: +haypo
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
Patch removing cpthread, pth, lwp and solaris thread implementations. The patch
on configure.in, around the following diff, is invalid:
AC_DEFINE(_REENTRANT)
-AC_CHECK_HEADER(cthreads.h, [AC_DEFINE(WITH_THREAD)
-AC_DEFINE(C_THREADS
STINNER Victor added the comment:
FYI Hurd only supports cthread, without cthread support, Python will not
support threads on Hurd anymore.
There are two Hurd issues to move from cthread to pthread
http://savannah.gnu.org/task/?5487 (opened 5 years ago)
http://savannah.gnu.org/task/?7895
STINNER Victor added the comment:
Oh, it remembers a long story around ext3/ext4 and write barrier, with a
specific problem in Firefox with SQLite.
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/fsync.2.html
" For applications that require ti
STINNER Victor added the comment:
> Most of these names will be removed in 3.3:
> http://bugs.python.org/issue11863
Yeah, I know. My patch should be updated if #11863 is fixed before this issue.
Updated patch:
- add 'pthread_version' key to threading._info()
- test_os uses
STINNER Victor added the comment:
Example on my Debian Sid:
>>> threading._info()
{'pthread_version': 'NPTL 2.11.2', 'use_semaphores': True, 'name': 'pthread'}
--
___
STINNER Victor added the comment:
Python/thread.c contains a reference to a missing file:
#ifdef PLAN9_THREADS
#include "thread_plan9.h"
#endif
But I don't see where PLAN9_THREADS is defined.
remove_threads.patch removes these 3 lines.
--
There is also an unused file: Python
STINNER Victor added the comment:
> The path which sets "pthread_version" should be inside "#ifdef
> _POSIX_THREADS".
> Also, some comments about the doc:
> - you need a "versionadded" tag
Right, fixed.
> - "use_semaphores" should expla
STINNER Victor added the comment:
Let's wait 6 hours for "x86 FreeBSD 6.4 3.x":
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x
The first build including my fix (383a7301616b) should be:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206
STINNER Victor added the comment:
signal_pthread_sigmask.patch:
- add signal.pthread_sigmask() function with doc and tests
- add SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK constants
- fix #11859: fix tests of test_io using threads and an alarm: use
pthread_sigmask() to ensure that only the main
Changes by STINNER Victor :
--
dependencies: +expose signalfd(2) and sigprocmask(2) in the signal module
___
Python tracker
<http://bugs.python.org/issue11
STINNER Victor added the comment:
Oh, I forget to read again http://codereview.appspot.com/1132041.
Here is an updated patch reusing some tests and with a better documentation.
--
Added file: http://bugs.python.org/file21736/signal_pthread_sigmask-2.patch
STINNER Victor added the comment:
> c) parse_source_module()
> => covered by the issue #10785.
Issue #10785 didn't change parse_source_module(): it does still encode the
filename.
We need Unicode version of PyParser_ASTFromFile() and PyAST_Compile(): a new
version of t
STINNER Victor added the comment:
"Builder x86 FreeBSD 6.4 3.x Build #1394. Results: Build successful"
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1394
Great! It should be the first success on this buildbot since... 4 months
(r87292, issue #884
Changes by STINNER Victor :
--
title: test_mmap timeout (1 hour) on "AMD64 Snow Leopard 3.x" buildbot ->
test_mmap.test_large_offset() timeout (1 hour) on "AMD64 Snow Leopard 3.x"
buildbot
___
Python tracker
<http://
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.
Wrong, it was a deadlock. It is a duplicate of #11768 and it is now
2801 - 2900 of 35168 matches
Mail list logo
