date:20100416


Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> committed/rejected

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment


Eugene Kapun  added the comment:

Empty string is an iterable of integers in the range 0 <= x < 256, so it should 
be allowed.

>>> all(isinstance(x, int) and 0 <= x < 256 for x in "")
True
>>> bytearray()[:] = ""
Traceback (most recent call last):
  File "", line 1, in 
TypeError: string argument without an encoding

--

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment


Ezio Melotti  added the comment:

Not really, chars are not ints and anyway the empty string fall in the first 
case.

--

___
Python tracker 

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

[issue8417] bytes and bytearray constructors raise TypeError for very large ints


New submission from Eugene Kapun :

>>> bytes(10)
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> bytes(10 ** 100)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object is not iterable

--
components: Interpreter Core
messages: 103300
nosy: abacabadabacaba
severity: normal
status: open
title: bytes and bytearray constructors raise TypeError for very large ints
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue1766304] improve xrange.contains


Changes by Eugene Kapun :


--
nosy: +abacabadabacaba

___
Python tracker 

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

[issue1766304] improve xrange.contains


Mark Dickinson  added the comment:

I suggest closing this:  it's been implemented (for range) in Python 3.x, and I 
think it's too late for 2.x now.

--

___
Python tracker 

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

[issue1766304] improve xrange.contains


Changes by Mark Dickinson :


--
versions:  -Python 3.2

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment


Eugene Kapun  added the comment:

> Not really, chars are not ints
Yes, however, empty string contains exactly zero chars.
> and anyway the empty string fall in the first case.
Strings aren't mentioned in documentation of bytearray slice assignment. 
However, I think that bytearray constructor should accept empty string too, 
without an encoding, for consistency.

--

___
Python tracker 

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

[issue8355] diff.py produce unified format by default

2010-04-16 Thread anatoly techtonik


anatoly techtonik  added the comment:

I am not convinced with -1 +1 argumentation. Can somebody properly summarize 
arguments behind the decision? Democracy is good, but it is a pity to see a 
technical proposal fail because of personal reasons.

--
status: pending -> open

___
Python tracker 

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

[issue8417] bytes and bytearray constructors raise TypeError for very large ints


Changes by Ezio Melotti :


--
nosy: +ezio.melotti
priority:  -> normal
stage:  -> unit test needed
versions: +Python 2.6, Python 2.7, Python 3.2

___
Python tracker 

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

[issue8355] diff.py produce unified format by default

2010-04-16 Thread anatoly techtonik


anatoly techtonik  added the comment:

I.e. if you put a -1 or +1 - put it with a short sentence that summarizes the 
key factor in your decision. There is no +0 or -0 that are used to give 
everybody else a hint about your feelings towards.


For example:
+1 - I use patch.py diff.py counterpart that accepts only unified diffs without 
any options, so it would be nice if diff.py generated unified diffs without any 
options as well

-1 - I don't use diff.py to generate my diffs, I do not care that it is not a 
part of standard library, I know that it's output format is incompatible with 
unix diff(1) format, and I still want diff.py to generate incompatible context 
diffs by default, even though I could always generate them with -c option

--

___
Python tracker 

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

[issue8413] String interpolation doesn't work with sys.version_info


Eric Smith  added the comment:

This affects any type implemented as PyStructSequence. For example, sys.flags 
has the same behavior.

--
components: +Interpreter Core -Library (Lib)
priority:  -> normal
type:  -> behavior

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment


Eugene Kapun  added the comment:

__doc__ of bytearray says:
> bytearray(iterable_of_ints) -> bytearray
> bytearray(string, encoding[, errors]) -> bytearray
> bytearray(bytes_or_bytearray) -> mutable copy of bytes_or_bytearray
> bytearray(memory_view) -> bytearray
So, unless an encoding is given, empty string should be interpreted as an 
iterable of ints. BTW, documentation and docstring should be made consistent 
with each other.

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD


Mark Dickinson  added the comment:

> Mark, did your initial backtrace look like this:

No;  the segfault was definitely happening in delwin rather than putwin.  But I 
did see something like your backtrace when I tried to use ncurses from ports 
(installed in /usr/local) rather than the system ncurses.  This was all on 
FreeBSD 8.0/amd64, by the way, running in a VM on Parallels.  I got the same 
results both when working directly within the VM terminal, and when ssh'ing to 
the VM from an OS X Terminal.

Maybe running this through Valgrind or something similar might show what's 
going on.  (Though it's not clear from a quick google whether Valgrind works on 
FreeBSD.)

--

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

2010-04-16 Thread Stefan Krah


Stefan Krah  added the comment:

Valgrind can be installed by:

cd /usr/ports/devel/valgrind && make install


Then you can do (curses_test.py is your short test program):

1) valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python 
curses_test.py

2) valgrind --suppressions=Misc/valgrind-python.supp ./python curses_test.py


Valgrind finds invalid writes. The problem with 1) is that the
terminal is in an unusable state, so controlling gdb isn't possible.

The best thing is probably to use 2) and wade through the unformatted
output starting here:

 ==12043== Invalid write of size 8
 ==12043==at 0x27A71B7: getwin (in/li /libncursesw.so.8)
 ==12043==by 
0x2A3EAAB: PyCurses_GetWin (_cursesmodule.c:1902)
   ==12043==by 0x4573FB: PyEval_EvalFrameEx (ceval.c:3833)
  ==12043==
by 0x457DF9: PyEval_EvalCodeEx (ceval.c:3282)


(I don't have time to do that right now, I might do it later.)

--
nosy: +skrah

___
Python tracker 

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

[issue762963] timemodule.c: Python loses current timezone

2010-04-16 Thread Grant Bowman


Grant Bowman  added the comment:

Is there anything others like me can do to help get this fixed?

--
nosy: +grantbow

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-16 Thread David Beazley


David Beazley  added the comment:

I'm sorry, but even in the presence of fair locking, I still don't like this 
patch.   The main problem is that it confuses fair locking with fair CPU 
use---something that this patch does not and can not achieve on any platform.

The main problem is that everything is still based on the execution of 
interpreter ticks.  However, interpreter ticks have wildly varying execution 
times dependent upon the code that's running.   Thus, executing 1000 ticks 
might take significantly longer in one thread than another.   Under a FIFO 
scheduler based on "fair" locking, the thread with the longer-running ticks is 
going to unfairly hog the GIL and the CPU.  For example, if thread 1 takes 95 
usec to execute 1000 ticks and thread 2 takes 5 usec to execute 1000 ticks, 
then thread 1 is going to end up hogging about 95% of the CPU cycles, starving 
thread 2.   To me, that doesn't sound especially "fair." 

It would be much better to have fairness where threads are guaranteed to get an 
equal time slice of CPU cycles regardless of how many ticks they're executing.  
In other words, it would be much better if the two threads above each got 50% 
of the CPU cycles.   The only way you're ever going to be able to do that is to 
base thread scheduling on timing.   The new GIL in Python 3 makes an effort to 
do this even though some issues are still being worked out with it.

On a slightly unrelated note, I just tried some experiments on Linux with the 
GIL implemented as condition variables and with semaphores.   I honestly didn't 
see any noticeable performance difference between the two versions.  I also 
didn't see any kind of purported "fair" scheduling of threads using the 
semaphore version.  Both versions exhibit the same performance problems as 
described in my GIL talk (albeit not to the same extreme as on OS-X).  Based on 
my own reading of the pthreads source code (yes, I have looked), I can't really 
draw any conclusion about the fairness of semaphores.   Under the covers, it's 
all based on futex locks (the "f" in futex referring to "fast", not "fair" by 
the way). I know that the original paper on futexes has some experiments with 
fair lock scheduling, but I honestly don't know if that is being used in the 
Linux kernel or by pthreads.   My understanding is that by default, futexes do 
not guarantee fairness.  To know for certain with semaphor
 es, much more low-level investigation would be required.

--

___
Python tracker 

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

[issue8413] String interpolation doesn't work with sys.version_info


Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> unit test needed

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-16 Thread David Beazley


David Beazley  added the comment:

I've attached a test "fair.py" that gives an example of the fair CPU scheduling 
issue.  In this test, there are two threads, one of which has fast-running 
ticks, one of which has slow-running ticks.  

Here is their sequential performance (OS-X, Python 2.6):

slow: 5.71
fast: 0.32

Here is their threaded performance (OS-X, Python 2.6.4):

slow : 5.99
fast : 6.04(Notice : Huge jump in execution, unfair CPU)

Here is their threaded performance using the Py3K New GIL:

slow : 5.96
fast : 0.67(Notice : Fair CPU use--time only doubled)

Using Linux with semaphores gives no benefit here.  The fast code is stalled in 
the same way.   For example: here are my Linux results (Ubuntu 8.10, 
Python-2.6.4, dual-core, using semaphores):

Sequential:
slow : 6.24
fast : 0.59
Threaded:
slow : 6.40
fast : 6.69(even slower than the slow code!)

--
Added file: http://bugs.python.org/file16946/fair.py

___
Python tracker 

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

[issue2987] RFC2732 support for urlparse (IPv6 addresses)

2010-04-16 Thread Senthil Kumaran


Senthil Kumaran  added the comment:

Reverted the check-in made to 3.1 maint (in r80104). Features should not go in 
there.

--

___
Python tracker 

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

[issue8410] Fix emulated lock to be 'fair'

2010-04-16 Thread Kristján Valur Jónsson


Kristján Valur Jónsson  added the comment:

Martin, it isn't the condition variable which is unfair, but how the 
constructed locking apparatus is unfair that is the problem.  This lock is 
written by a Tim, whom I assume to be Tim Peters.  I quote his comment:  
"In general, if the bit can be acquired instantly, it is, else the pair is used 
to block the thread until the bit is cleared. 9 May 1994 t...@ksr.com"

Herein lies the problem.  This is the behaviour of "greedy" or "unfair" 
mutexes, not that of "fair" semaphores.  The lock is made 'free' and the just 
signaled thread has to _race_ to acquire it.

Since the exact mechanics seem to be unclair to many, let me just step you 
through the series of events.
1) A has the lock, B is waiting for it.  the bit is "set".
2) A releases the lock:  Clears the bit, signals the condition variable.
3) A tries to immediately reacquire the lock.  Sees the bit cleared, sets it, 
and claims the lock.
4) B wakes up from the condition variable.  Sees the bit "set" and goes back to 
sleep.  It has lost the race to A.

If the lock were based on a semaphore, the events would be different:
1) A has the semaphore, B is waiting for it, sem.value == 0
2) A releases (signals) the semaphore.  B is made runnable. sem.value stays at 0
3) A tries to immediately reacquire the lock.  Finds the sem.value at 0 and 
blocks.
4) B wakes up and executes, now the owner of the lock. sem.value stays at 0.

This particular patch implements the latter behaviour by explicitly entering a 
"handoff" period.  If you want, I can submit a different patch which emulates a 
semaphore perfectly.  perhaps that is easier to understand, since semaphores 
are very familiar to people.

The key difference between Tim's lock is that the semaphore "hands off" 
ownership to a particular waiting thread.  The semaphore doesn't enter a state 
of "free" so that thread have to race to lock it.  It is this race which is 
unfair and which the just-releasing lock almost always wins.

If you are asking "why would we want an unfair lock, then?", see issue 8299 
where I point out some links that discuss unfair locks and their role in 
combating lock convoys.


Antoine, if we have A, B, and C, all competing for the lock, at any one point, 
only one of the three has the lock.  Say, A.  The others are waiting on the 
condition variable.
Condition variables are generally implemented in a "fair" manner, so that all 
threads that "wait" on it are woken up in a roughly FIFO manner.  If not 
exactly, then at least in the long run.  All of the threads have to enter the 
condition variable's wait queue to acquire the lock.  Because of this, the lock 
is handed off to the threads in roughly the same order that they enter the 
condition variable´s wait state.

If, in your example, C is waiting on the condition variable, then A and B, 
whenever they give up the lock, they will hand it off a single thread which is 
woken up, typcally the one at the head of the condition variable's internal 
queue.  If the condition variable is implemented properly, there is no way that 
A and B can just flip-flop without C never being the thread to be woken up next.

As so often, the proof is in the pudding.  Try your ccprof.py script with the 
do_yield turned off.
You can also implement an explicitly FIFO condition variable, as I did in issue 
8299, if you don't trust the condition variable's own internal mechanism to 
treat its waiting threads fairly.

--

___
Python tracker 

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

[issue8412] os.system() doesn't support surrogates nor bytes


STINNER Victor  added the comment:

Commited to py3k as r80105. Let see if buildbots are happy or not :-)

--

___
Python tracker 

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

[issue8413] String interpolation doesn't work with sys.version_info


Changes by R. David Murray :


--
nosy: +rhettinger

___
Python tracker 

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

[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots


STINNER Victor  added the comment:

> Committed as r79892.

Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses 
libffi 3.0.5.

--
nosy: +haypo
status: pending -> open

___
Python tracker 

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

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32


STINNER Victor  added the comment:

Commited as r80108 to py3k: "Add CS_GNU_LIBC_VERSION and 
CS_GNU_LIBPTHREAD_VERSION constants for constr(), and disable 
test_execvpe_with_bad_program() of test_os if the libc uses linuxthreads to 
avoid the "unknown signal 32" bug (see issue #4970)."

Wait for the buildbot to port it to trunk (and maybe 2.6 and 3.1).

--

___
Python tracker 

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

[issue8405] Improve test_os._kill (failing on slow machines)


STINNER Victor  added the comment:

With the patch, the test have 1.0 second to succeed. I would prefer 5.0 or 10.0 
seconds: it should not waste the 10 seconds because it should succeed if a new 
milliseconds. But if the machine is "slow" (which is the topic of the issue), 
you can give some more seconds to the test. So max=100, sleep=0.1

--
nosy: +haypo

___
Python tracker 

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

[issue8412] os.system() doesn't support surrogates nor bytes


STINNER Victor  added the comment:

> Commited to py3k as r80105

The buildbots look happy: backported to 3.1 as r80110.

--

___
Python tracker 

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

[issue8412] os.system() doesn't support surrogates nor bytes


Changes by STINNER Victor :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue8408] need console/pager module


R. David Murray  added the comment:

Benjamin was using the term 'bug' as a synonym for 'issue in the tracker'.  The 
point is that a feature like this (a whole new module) is not an appropriate 
tracker item.  In most cases the procedure for getting a new module included in 
the stdlib is distinctly non-trivial and generally requires, among other 
things, that the module get proven by distribution via PyPI first.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

2010-04-16 Thread Nir Aides


Changes by Nir Aides :


Removed file: http://bugs.python.org/file16830/bfs.patch

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

2010-04-16 Thread Nir Aides


Nir Aides  added the comment:

I uploaded an update to bfs.patch which improves behavior in particular on 
non-Linux multi-core (4+) machines. 

Hi Charles-Francois, Thanks for taking the time to review this patch!

> - nothing guarantees that you'll get a msec resolution

Right, the code should behave well with low precision clocks as long as short 
(sub-tick) tasks are not synchronized with the slice interval. There is a 
related discussion of this problem in schedulers in the section on sub-tick 
accounting in: http://ck.kolivas.org/patches/bfs/sched-BFS.txt

On which target systems can we expect not to have high precision clock?

> - gettimeofday returns you wall clock time: if a process that modifies time 
> is running, e.g. ntpd, you'll likely to run into trouble. the value returned 
> is _not_ monotonic, but clock_gettime(CLOCK_MONOTONIC) is
> - inline functions are used, but it's not ANSI
> - static inline long double get_timestamp(void) {
>struct timeval tv;
>GETTIMEOFDAY(&tv);
>return (long double) tv.tv_sec + tv.tv_usec * 0.01;
> }

I added timestamp capping to the code. timestamp is used for waiting and 
therefore I think the source should be either CLOCK_REALTIME or gettimeofday().

> > `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, 
> > which based its speculative operation on the number of elapsed opcodes (and 
> > which also gave bad latency numbers on the regex workload).
>
> I find this suspicous too. I haven't looked at the patch in detail, but what 
> does the number of elapsed opcodes offers you over the timesplice expiration 
> approach ?

More accurate yielding. It is possible a better mechanism can be thought of 
and/or maybe it is indeed redundant.

> It is thus recommended that a condition wait be enclosed in the equivalent of 
> a "while loop" that checks the predicate."

Done.

--
Added file: http://bugs.python.org/file16947/bfs.patch

___
Python tracker 

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

[issue762963] timemodule.c: Python loses current timezone


R. David Murray  added the comment:

Review the code, test the patch, confirm that it fixes the problem and doesn't 
break anything else, and report your results here.  That doesn't guarantee that 
it will get applied, but it definitely helps.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


Antoine Pitrou  added the comment:

> What do you think about my solution (convert the traceback to ASCII to
> avoid the encoding issue)?

It's fine for me. Perhaps you should add a comment to explain why this is 
necessary.

--

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


STINNER Victor  added the comment:

Commited: r80112 (py3k). Waiting for the buildbots before te backport to 3.1.

--

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch


R. David Murray  added the comment:

@Éric: even if you prepare the patches, I find I'm not interested in doing the 
checkins.  If someone else wants to take this on that's fine with me, but I'm 
not going to do it.

--
assignee: georg.brandl -> 

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit

2010-04-16 Thread Alf P. Steinbach

New submission from Alf P. Steinbach :

Python 3.1.1 in Windows XP Prof, appears to be a Windows-only problem

Effect: on program exit the interpreter crashes with exception 0xc417
STATUS_INVALID_CRUNTIME_PARAMETER at address 0x78588389, which appears to be in
[msvcr90.dll].

To reproduce: very difficult. I had this occur tree times when, after not
running any Python program for a while, hitting Ctrl C at the first prompt of
the enclosed program. On subsequent runs (not waiting) the bug does *not*
manifest. Possibly a timing issue?

Possibly the same bug: ticket #85 for PyInstaller, http://www.pyinstaller.org/ticket/85> has same exception code and same address
and also occurring at program exit. Reported as not manifesting in Linux, only
Windows. If same bug may be more reliable way to reproduce.

PS: I reported two or three bugs earlier; one was fixed in 3.1.2. But the "Your
issues" link shows no issues for me. Trying to report that via "Report tracker
problem" it doesn't recognize me as logged in, and maintains that my login
attempt is invalid. So there's like a bug in the tracker's reporting scheme for
reporting the bug in the tracker. :-)

--
components: Interpreter Core
files: sum.v4.py
messages: 103325
nosy: alfps
severity: normal
status: open
title: Crash 0xc417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file16948/sum.v4.py

___
Python tracker

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

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

2010-04-16 Thread Jean-Paul Calderone


Jean-Paul Calderone  added the comment:

> The one big difference I can see is that set_wakeup_fd() doesn't transmit the 
> signal number, but this could be fixed if desired (instead of sending '\0', 
> send a byte containing the signal number).

There's a lot more information than the signal number available as well.  The 
signalfd_siginfo struct has 16 fields in it now and may have more in the future.

Another advantage is that this approach allows all asynchronous preemption to 
be disabled.  This side-steps the possibility of hitting any signal bugs in 
CPython itself.  Of course, any such bugs that are found should be fixed, but 
fixing them is often quite challenging and involves lots of complex 
domain-specific knowledge.  In comparison, the signalfd and sigprocmask 
extensions are quite straight-forward and self-contained.

It's also possible to have several signalfds, each with a different signal 
mask.  set_wakeup_fd is limited to a single fd per-process.

sigprocmask has other uses all by itself, of course, like delaying the delivery 
of signals while some sensitive code runs.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

2010-04-16 Thread Nick Coghlan


Changes by Nick Coghlan :


--
assignee:  -> ncoghlan

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit

2010-04-16 Thread Alf P. Steinbach


Alf P. Steinbach  added the comment:

It now seems almost certain that it's /necessary/ to not have run any Python 
programs for a while (say, 10 minutes?) in order for the bug to manifest when 
using Ctrl C in the enclosed program.

Also, I forgot to mention, the SEH exception occurs *while the program is 
printing the traceback*.

Except that the last line is not displayed until the tell-Bill-Gates-about-it 
box is clicked away, it consistently manages to print


C:\Documents and Settings\Alf> sum.v4.py
This program computes the sum of two numbers A and B.

Number A, please: Traceback (most recent call last):
  File "C:\Documents and Settings\Alf\sum.v4.py", line 13, in 


When it doesn't crash it displays four more lines of traceback.

--

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit


R. David Murray  added the comment:

The meta-tracker (the tracker to report problems with the tracker) is a 
separate tracker and you have to create a new login there.  I agree that this 
is awkward, but nobody has stepped up to fix it yet.

'your issues' is issues assigned to you, and 'normal' users can never have 
issues assigned to them.  There's already an issue in the meta tracker about 
this.  You can use the 'search' interface to search for bugs created by 
you...sooner or later someone will submit a patch to the meta tracker to put 
such a search in the left hand menu.

I don't have any input on the windows bug, but I'll add Brian Curtin as nosy in 
case he has any thoughts.

--
nosy: +brian.curtin, r.david.murray
priority:  -> normal

___
Python tracker 

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

[issue7605] test_cmd_line fails with non-ascii path


STINNER Victor  added the comment:

The problem is that the print is failing because Python uses ASCII encoding for 
stdout. Attached patch encodes sys.path to ASCII using backslashreplace to 
avoid the encoding issue.

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16949/test_cmd_line.patch

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


New submission from Mark Dickinson :

In all versions of CPython right now, the following works.

>>> dict({1:2}, **{3:4})
{1: 2, 3: 4}

Other Python implementations raise TypeError for this;  CPython should probably 
do the same, beginning with deprecating this behaviour in Python 3.2 and 
removing it in 3.3.

>From a python-dev posting[1] by Alex Gaynor:

"""
I ran into the follow behavior while making sure Django works
correctly on PyPy.  The following behavior was observed in all tested
versions of CPython (2.5, 3.1):

>>> def f(**kwargs):
... print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
{1: 3}
>>> f(**kwargs)
Traceback (most recent call last):
 File "", line 1, in 
TypeError: f() keywords must be strings
>>>

This behavior seems pretty strange to me, indeed PyPy gives the
TypeError for both attempts.  I just wanted to confirm that it was in
fact intentional.
"""

Raghuram Devarakonda says (in the same python-dev thread):

"I ran into same issue with Django on Jython yesterday [1] since Jython
too gives TypeError for 'dict({}, **kwargs)'."

Guido, on the suggestion that both the CPython and PyPy behaviour be left as 
is, and that the behaviour be regarded as implementation defined:

"That is just going to cause some programs to have a portability
surprise. I think one or the other should be fixed. I am fine with declaring 
dict({}, **{1:3}) illegal, since after all it is abuse of the ** mechanism. We 
should deprecate it in at least one version though."


[1] http://mail.python.org/pipermail/python-dev/2010-April/099427.html

--
components: Interpreter Core
messages: 103330
nosy: mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: dict constructor allows invalid identifiers in **kwargs
type: behavior
versions: Python 3.2, Python 3.3

___
Python tracker 

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

[issue8417] bytes and bytearray constructors raise TypeError for very large ints


Changes by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Mark Dickinson  added the comment:

The issue applies to dict.update as well:

>>> d = {1:2}
>>> d.update({3:4}, **{5:6})
>>> d
{1: 2, 3: 4, 5: 6}

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Mark Dickinson  added the comment:

Update:  IronPython also produces a TypeError here (thanks Michael Foord and 
Dino Viehland).

--

___
Python tracker 

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

[issue8420] set_lookkey is unsafe


New submission from Eugene Kapun :

I've noticed that set_lookkey (in Objects/setobject.c) does some unsafe things:
Objects/setobject.c:
> if (entry->hash == hash) {
>   startkey = entry->key;
>   Py_INCREF(startkey);
>   cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
>   Py_DECREF(startkey);
At this point, object pointed to by startkey could be deallocated, and then new 
object may be allocated at the same address.
>   if (cmp < 0)
>   return NULL;
>   if (table == so->table && entry->key == startkey) {
At this point, the table may be reallocated at the same address but with 
different (possibly smaller) size, so entry->key may be in deallocated memory. 
Also, entry->key may be equal to startkey but still point to an object other 
than one key was compared with.
>   if (cmp > 0)
>   return entry;
>   }
>   else {
>   /* The compare did major nasty stuff to the
>* set:  start over.
>*/
>   return set_lookkey(so, key, hash);
This can lead to infinite recursion.
>   }

--
components: Interpreter Core
messages: 10
nosy: abacabadabacaba
severity: normal
status: open
title: set_lookkey is unsafe
versions: Python 3.1

___
Python tracker 

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

[issue7605] test_cmd_line fails with non-ascii path


STINNER Victor  added the comment:

Fixed: r80116 (py3k), r80117 (3.1).

--

___
Python tracker 

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

[issue7605] test_cmd_line fails with non-ascii path


Changes by STINNER Victor :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


STINNER Victor  added the comment:

> Commited: r80112 (py3k)

Looks good: r80118 (3.1).

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue8420] set_lookkey is unsafe


Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue8413] String interpolation doesn't work with sys.version_info


Changes by Raymond Hettinger :


--
priority: normal -> high

___
Python tracker 

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

[issue1766304] improve xrange.contains


Raymond Hettinger  added the comment:

As an implementation detail, it isn't too late to put this into 2.x if it is 
something we care about.

--
priority: normal -> low

___
Python tracker 

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

[issue8421] tiger buildbot: unable to resolv hostname address


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 
3.x/builds/6/steps/test/logs/stdio:
==
ERROR: testSockName (test.test_socket.GeneralModuleTests)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_socket.py", 
line 504, in testSockName
my_ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno 7] No address associated with nodename

--
messages: 103337
nosy: haypo
severity: normal
status: open
title: tiger buildbot: unable to resolv hostname address
versions: Python 3.2

___
Python tracker 

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

[issue8422] tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 
3.x/builds/6/steps/test/logs/stdio

test test_ntpath failed -- Traceback (most recent call last):
  File 
"/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_genericpath.py", 
line 288, in test_abspath_issue3426
with support.temp_cwd(b'\xe7w\xf0'):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/contextlib.py", line 
17, in __enter__
return next(self.gen)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 
392, in temp_cwd
os.mkdir(name)
OSError: [Errno 22] Invalid argument

As discussed on IRC: Mac OS X deny the creation of a directory with an invalid 
utf8 name. The test should be skipped on Mac OS X (sys.platform == 'darwin').

--
messages: 103338
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)

___
Python tracker 

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

[issue8422] tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)


Changes by STINNER Victor :


--
components: +Library (Lib)
versions: +Python 3.2

___
Python tracker 

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

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32


Mark Dickinson  added the comment:

Fix merged to release31-maint in r80119.  Thanks, Victor.

--
components: +Tests
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> crash

___
Python tracker 

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

[issue8423] tiger buildbot: test_pep277 failures


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 
3.x/builds/6/steps/test/logs/stdio

test test_pep277 failed -- multiple errors occurred; run in verbose mode for 
details
Re-running test test_pep277 in verbose mode
test_directory (test.test_pep277.UnicodeFileTests) ... ok
test_failures (test.test_pep277.UnicodeFileTests) ... ok
test_listdir (test.test_pep277.UnicodeFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeFileTests) ... ERROR
test_open (test.test_pep277.UnicodeFileTests) ... ok
test_rename (test.test_pep277.UnicodeFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFDFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFKCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFKDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKDFileTests) ... ok

==
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
--
test test_pep277 crashed -- : 'ascii' codec can't 
encode characters in position 222-239: ordinal not in range(128)
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", 
line 195, in test_main
UnicodeNFKDFileTests,
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 
1000, in run_unittest
_run_suite(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 
974, in _run_suite
result = runner.run(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 158, in run
result.printErrors()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 108, in printErrors
self.printErrorList('ERROR', self.errors)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 116, in printErrorList
self.stream.writeln("%s" % err)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 24, in writeln
self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 222-239: 
ordinal not in range(128)

--
messages: 103340
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_pep277 failures
versions: Python 3.2

___
Python tracker 

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

[issue8424] tiger buildbot: test_itimer_virtual failures


New submission from STINNER Victor :

test_itimer_virtual (test.test_signal.ItimerTest) ... FAIL

==
FAIL: test_itimer_prof (test.test_signal.ItimerTest)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", 
line 391, in test_itimer_prof
self.fail('timeout waiting for sig_prof signal')
AssertionError: timeout waiting for sig_prof signal

==
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", 
line 372, in test_itimer_virtual
(signal.getitimer(self.itimer),))
AssertionError: timeout waiting for sig_vtalrm signal; 
signal.getitimer(self.itimer) gives: (0.29, 0.2)

--
Ran 13 tests in 15.302s

--
messages: 103341
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_itimer_virtual failures
versions: Python 3.2

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Mark Dickinson  added the comment:

It's a bit ambiguous:  the object being supplied to the Decimal constructor 
does have the right type (tuple), but the wrong contents (i.e., value).  So you 
could argue either way on this, I guess.

--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set


New submission from Eugene Kapun :

>>> small_set = set(range(2000))
>>> large_set = set(range(2000))
>>> large_set -= small_set # Fast
>>> small_set -= large_set # Slow, should be fast
>>> small_set = small_set - large_set # Fast

--
components: Interpreter Core
messages: 103343
nosy: abacabadabacaba
severity: normal
status: open
title: a -= b should be fast if a is a small set and b is a large set
type: resource usage
versions: Python 3.1

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Raymond Hettinger  added the comment:

I don't think this is worth the performance hit or worth the deprecate/remove 
exercise.  I agree with Guido that we just call this an undefined, 
implementation specific behavior.

This behavior has existed for a very long time with no ill-effects.  Marking as 
low priority.

--
nosy: +rhettinger
priority: normal -> low

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment


Martin v. Löwis  added the comment:

-1 on assigning strings to slices of bytearrays. As Ezio mentions, this 
operation conceptually requires an encoding, and no encoding is readily 
available in the slice assignment.

-1 on special-casing empty strings.

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Mark Dickinson  added the comment:

> I agree with Guido that we just call this an undefined, implementation 
> specific behavior.

Actually I think that was exactly what Guido was *disagreeing* with.  :)

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Eric Smith  added the comment:

I agree with Mark. Guido's point was that if it's implementation defined, 
you'll have portability problems: 
http://mail.python.org/pipermail/python-dev/2010-April/099435.html

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs

2010-04-16 Thread Alex


Alex  added the comment:

Guido seems to be favoring disallowing it, not ignoring it[0].

http://mail.python.org/pipermail/python-dev/2010-April/099435.html

--
nosy: +alex

___
Python tracker 

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

[issue8426] multiprocessing.Queue fails to get() very large objects

2010-04-16 Thread Ian Davis


New submission from Ian Davis :

I'm trying to parallelize some scientific computing jobs using 
multiprocessing.Pool.  I've also tried rolling my own Pool equivalent using 
Queues.  In trying to return very large result objects from Pool.map()/imap() 
or via Queue.put(), I've noticed that multiprocessing seems to hang on the 
receiving end.  On Cygwin 1.7.1/Python 2.5.2 it hangs with no CPU activity.  On 
Centos 5.2/Python 2.6.2 it hangs with 100% CPU.  cPickle is perfectly capable 
of pickling these objects, although they may be 100's of MB, so I think it's 
the communication.  There's also some asymmetry in the error whether it's the 
parent or child putting the large object.  The put does appear to succeed;  
it's the get() on the other end that hangs forever.

Example code:
-
from multiprocessing import *

def child(task_q, result_q):
while True:
print "  Getting task..."
task = task_q.get()
print "  Got task", task[:10]
task = task * 1
print "  Putting result", task[:10]
result_q.put(task)
print "  Done putting result", task[:10]
task_q.task_done()

def parent():
task_q = JoinableQueue()
result_q = JoinableQueue()
worker = Process(target=child, args=(task_q,result_q))
worker.daemon = True
worker.start()
#tasks = ["foo", "bar", "ABC" * 1, "baz"]
tasks = ["foo", "bar", "ABC", "baz"]
for task in tasks:
print "Putting task", task[:10], "..."
task_q.put(task)
print "Done putting task", task[:10]
task_q.join()
for task in tasks:
print "Getting result..."
print "Got result", result_q.get()[:10]

if __name__ == '__main__':
parent()
-

If run as is, I get
Traceback (most recent call last):
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 242, in _feed
send(obj)
MemoryError: out of memory
(*** hangs, I hit ^C ***)
Got result
Traceback (most recent call last):
Process Process-1:
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in 
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py",
 line 237, in _bootstrap
parent()
  File "cygwin_multiprocessing_queue.py", line 29, in parent
print "Got result", result_q.get()[:10]
self.run()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py",
 line 93, in run
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 91, in get
self._target(*self._args, **self._kwargs)
  File "cygwin_multiprocessing_queue.py", line 6, in child
res = self._recv()
KeyboardInterrupt
task = task_q.get()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 91, in get
res = self._recv()
KeyboardInterrupt


If instead I comment out the multiplication in child() and uncomment the large 
task in parent(), then I get
  Getting task...
Putting task foo ...
Done putting task foo
Putting task bar ...
  Got task foo
  Putting result foo
Done putting task bar
Putting task ABCABCABCA ...
Done putting task ABCABCABCA
Putting task baz ...
  Done putting result foo
  Getting task...
  Got task bar
  Putting result bar
  Done putting result bar
  Getting task...
Done putting task baz
(*** hangs, I hit ^C ***)
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in 
parent()
  File "cygwin_multiprocessing_queue.py", line 26, in parent
task_q.join()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 303, in join
self._cond.wait()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/synchronize.py",
 line 212, in wait
self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt

--
components: Library (Lib)
messages: 103349
nosy: Ian.Davis
severity: normal
status: open
title: multiprocessing.Queue fails to get() very large objects
type: crash
versions: Python 2.5, Python 2.6

___
Python tracker 

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

[issue8421] tiger buildbot: unable to resolv hostname address


Martin v. Löwis  added the comment:

David, can you take a look?

--
nosy: +db3l, loewis

___
Python tracker 

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

[issue8422] tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)


Changes by Martin v. Löwis :


--
keywords: +buildbot

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Raymond Hettinger  added the comment:

A ValueError seems more appropriate to me.

--
nosy: +rhettinger

___
Python tracker 

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

[issue8423] tiger buildbot: test_pep277 failures


Changes by Martin v. Löwis :


--
keywords: +buildbot

___
Python tracker 

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

[issue8424] tiger buildbot: test_itimer_virtual failures


Changes by Martin v. Löwis :


--
keywords: +buildbot

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set


Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue8273] move test_support into the unittest package


R. David Murray  added the comment:

I'm writing unittests for a program I'm writing, and would really love to be 
able to use captured_stdout/stderr.  Of course, I have to support Python 2.5, 
and can't really justify installing unittest2, so I'll have to roll my own 
anyway, but I'm definitely +1 for those functions to move into unittest.  A 
bunch of the others, too, but that's the one I just looked at, and the API 
looks good to me.  (I'd rename captured_output and leave it be an 
implementation detail.)

How about 'tools' for the submodule name?

--

___
Python tracker 

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

[issue8273] move test_support into the unittest package


Raymond Hettinger  added the comment:

-1 on moving the module into the mainstream without significant reworking and 
rethinking.  This module is a junk collection (I know because I've contributed 
some it).

The unittest module is important.  It needs a super clean, well thought out 
API.  The test_support module doesn't qualify.

--
nosy: +rhettinger

___
Python tracker 

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

[issue8273] move generally useful test_support functions into the unittest package


Changes by R. David Murray :


--
title: move test_support into the unittest package -> move generally useful 
test_support functions into the unittest package

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m


Antoine Pitrou  added the comment:

After thinking a bit about it, we're in quasi-feature freeze now for 2.x and it 
doesn't sound reasonable to add options to unwrap(); we would need to write 
tests to exercise these options and their behaviour. Also, they aren't strictly 
needed to fix the issues at hand, but provide a functional benefit.

So I've taken some of Darryl's ideas and fixes and incorporated them. Here is a 
new patch with them. I've checked compatibility with OpenSSL 1.0.0 and 0.9.8k. 
If nobody manifests him/herself I will commit it soon.

(note: I dropped the idea of checking for application data with SSL_peek(), 
since it seems to be a blocking call; at least one of the test_ssl test cases 
froze here)

--
Added file: http://bugs.python.org/file16950/newssl6.patch

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-16 Thread Kristján Valur Jónsson


Kristján Valur Jónsson  added the comment:

What your fair.py is doing is demonstrating the superior behaviour of a 
time-based GIL interrupt to a bytecode based one.  I have no quibbles with that 
and I agree that it is superior.  But I also think that your example is a very 
artificial one.  On average the duration of the bytecodes evens out between 
threads and so they should give a fair first approximation.

But this is not what I was talking about when considering fairness.  Your test 
only measures each thread end to end, and it demonstrates how a bytecode based 
gil yilelding system wil let the two threads work in lockstep, even though each 
loop in one thread is cheaper than the other.  Fair enough.  But fair 
scheduling between threads doesn't show up here.

To demonstrate fair / unfair, I've modified fair.py to add two more runs, where 
three threads of the "fast" variety are run for identical number of rounds.  
This is when you will se a difference between the linux and the mac based GIL 
implementations.  For your info, on my windows dual core office box, with 
regular windows gil:

D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py
Sequential execution
slow: 3.384000 (0 left)
fast: 0.177000 (0 left)
Threaded execution
slow: 3.435000 (0 left)
fast: 3.568000 (0 left)
Treaded, balanced execution:
fast A: 0.973000 (0 left)
fast C: 0.992000 (0 left)
fast B: 1.013000 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 0.977000 (0 left)
fast C: 0.976000 (252 left)
fast B: 0.978000 (17601 left)

And now, same box, with the unfair GIL:

D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py
Sequential execution
slow: 3.338000 (0 left)
fast: 0.177000 (0 left)
Threaded execution
fast: 0.382000 (0 left)
slow: 3.539000 (0 left)
Treaded, balanced execution:
fast A: 0.362000 (0 left)
fast B: 0.464000 (0 left)
fast C: 0.549000 (0 left)
Treaded, balanced execution, with quickstop:
fast B: 0.389000 (0 left)
fast A: 0.447000 (240480 left)
fast C: 0.36 (613098 left)

The two last cases are the interesting ones.  With unfair scheduling, one 
thread takes almost twice as long to complete its 100 inserts than another. 
 And if they are all stopped when the quickest one finishes, one thread has 
more than 60 iterations to go.

This is what I mean by fair/unfair scheduling.

Cheers,

Kristján

p.s.  Yes, I agree that time based GIL yielding is better.  I intentionally 
didn't want to confuse the matter with that in 2.x.  I wanted to address the 
other issues that are wrong.

--
Added file: http://bugs.python.org/file16951/fair.py

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Mark Dickinson  added the comment:

>From both practical and purity points of view I think I prefer TypeError for 
>the cases Stefan gives: if you're passing a float for the sign, then you've 
>somehow ended up with the wrong type for that sign, and that's a TypeError 
>rather than a ValueError.

--

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Antoine Pitrou  added the comment:

A set_ciphers() method turns out to be highly impractical, since the underlying 
SSL objects are created lazily when we actually connect the socket.
Therefore, I have instead opted for a new "ciphers" argument to the SSL 
constructor(s). Patch attached.

--
keywords: +patch
Added file: http://bugs.python.org/file16952/ciphers.patch

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file16952/ciphers.patch

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Changes by Antoine Pitrou :


Added file: http://bugs.python.org/file16953/ciphers.patch

___
Python tracker 

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

[issue8427] toplevel jumps to another location on the screen

2010-04-16 Thread Andrei Paraschivescu


New submission from Andrei Paraschivescu :

The effect is the window just jumps to another location, matching left corners 
with another window in the same Python application. Its size doesn't change. 

The effect is somewhat erratic, the best I've been able to create is a 
situation where it happens 90% of the time. The application contains a number 
of widget.after calls, and I have not been able to replicate it with a small 
example.

I am running Mac OS X 10.4.11 and Python 2.6; running from my PC with Windows 
XP the effect doesn't happen, so it might be a OS X/Tk issue.

--
components: Tkinter
messages: 103358
nosy: aparasch
severity: normal
status: open
title: toplevel jumps to another location on the screen
versions: Python 2.6

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


New submission from STINNER Victor :

Example: http://www.python.org/dev/buildbot/3.x/builders/x86 FreeBSD 7.2 
3.x/builds/480/steps/test/logs/stdio

---
test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py",
 line 737, in test_notify_all
self.assertReturnsIfImplemented(6, get_value, woken)
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py",
 line 111, in assertReturnsIfImplemented
return self.assertEqual(value, res)
AssertionError: 6 != 5

Re-running test test_multiprocessing in verbose mode
test_array (test.test_multiprocessing.WithProcessesTestArray) ... skipped 
'requires _ctypes'
test_getobj_getlock_obj (test.test_multiprocessing.WithProcessesTestArray) ... 
skipped 'requires _ctypes'
test_rawarray (test.test_multiprocessing.WithProcessesTestArray) ... skipped 
'requires _ctypes'
test_notify (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_notify_all (test.test_multiprocessing.WithProcessesTestCondition) ... FAIL
test_timeout (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_connection (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_duplex_false (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_sendbytes (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_spawn_close (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_event (test.test_multiprocessing.WithProcessesTestEvent) ... ok
test_finalize (test.test_multiprocessing.WithProcessesTestFinalize) ... ok
test_heap (test.test_multiprocessing.WithProcessesTestHeap) ... ok
test_import (test.test_multiprocessing.WithProcessesTestImportStar) ... ok
test_listener_client 
(test.test_multiprocessing.WithProcessesTestListenerClient) ... ok
test_lock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_lock_context (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_rlock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_enable_logging (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_level (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart) 
... ok
test_apply (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async_timeout (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap_unordered (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_make_pool (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map_chunksize (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_terminate (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_pool_worker_lifetime 
(test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime) ... 
command timed out: 1800 seconds without output, killing pid 87365
process killed by signal 9
program finished with exit code -1
elapsedTime=6317.267055
---

--
keywords: buildbot
messages: 103359
nosy: haypo
severity: normal
status: open
title: buildbot: test_multiprocessing timeout
versions: Python 3.2

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Raymond Hettinger  added the comment:

Does this mean that every time someone uses **kwds, that the entire dictionary 
will need to be scanned for invalid keys?  So every API that accepts and passes 
through **kwds will be slowed on every time it is called.  Is there any 
offsetting benefit?

--

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Raymond Hettinger  added the comment:

I could see a TypeError for the outer tuple a tuple wasn't passed-in.  If the 
contents aren't what we expect, I believe that calling it a ValueError is the 
Python way.

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

They are already checked for pure python functions.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Antoine Pitrou  added the comment:

New patch updating docs.

--
Added file: http://bugs.python.org/file16954/ciphers2.patch

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Changes by Antoine Pitrou :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

Here's a patch. It adds a new function, PyArg_ValidateKeywordArguments.

--
keywords: +patch
Added file: 
http://bugs.python.org/file16955/no_dict_non_string_keyword_args.patch

___
Python tracker 

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

[issue8421] tiger buildbot: unable to resolv hostname address

2010-04-16 Thread David Bolen


David Bolen  added the comment:

Looks like some initial configuration glitches - the buildbot needed a little 
convincing to go to the DNS server for gethostbyname().  Should be working now.

--

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set


Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

And here's a patch for the correct Python version...

--
Added file: http://bugs.python.org/file16956/no_dict_non_string_kwarg.patch

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


STINNER Victor  added the comment:

The error occurs on buildbots:
 - i386 Ubuntu 3.x (r80115)
 - x86 FreeBSD 7.2 3.x (r80116, r80075)
 - x86 XP-4 3.x (r80115, r80106)

--

___
Python tracker 

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

[issue8429] buildbot: test_subprocess timeout


New submission from STINNER Victor :

test_subprocess hungs for 30 min or more.

The bug occurs on buildbots:
 - ARMv7Thumb Ubuntu 3.1 (r80093)
 - ARMv4 Debian 3.x (r80102)
 - ARMv7Thumb Ubuntu 3.x (r80020)
 - alpha Debian 3.x (r80020)
 - x86 FreeBSD 7.2 3.x (r80102)
 - sparc Debian trunk (r80085)

--
keywords: buildbot
messages: 103368
nosy: haypo
severity: normal
status: open
title: buildbot: test_subprocess timeout
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue762963] timemodule.c: Python loses current timezone

2010-04-16 Thread Paul Boddie


Paul Boddie  added the comment:

Well, this still doesn't work for me. I'm running Kubuntu 8.04 (libc6 package 
version 2.7-10ubuntu5) and reside in the CEST time zone, yet attempting to 
display the time zone always seems to give "+". Here are the failing tests, 
too:

==
FAIL: test_tm_gmtoff1 (__main__.TimeTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 225, in test_tm_gmtoff1
time.strftime("%z"), time.strftime("%z", time.localtime()))
AssertionError: '+0200' != '+'

==
FAIL: test_tm_gmtoff2 (__main__.TimeTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 238, in test_tm_gmtoff2
time.strftime("%z", time.localtime()), "+")
AssertionError: '+' == '+'

--

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

2010-04-16 Thread Charles-Francois Natali


Charles-Francois Natali  added the comment:

It's definitely a stack overflow.
Most of the backtraces show an important number of frames.
The last frame is this:
#0  PyMarshal_ReadLastObjectFromFile (fp=0x13e8200)
at ../Python/marshal.c:1026
filesize = 

and a disassembly show us that the segfault is generated on a callq:
0x4bd4d6 : callq  0x4168e8 

And if you look at the code, it's obvious what's happening:
PyObject *
PyMarshal_ReadLastObjectFromFile(FILE *fp)
{
/* 75% of 2.1's .pyc files can exploit SMALL_FILE_LIMIT.
 * REASONABLE_FILE_LIMIT is by defn something big enough for Tkinter.pyc.
 */
#define SMALL_FILE_LIMIT (1L << 14)
#define REASONABLE_FILE_LIMIT (1L << 18)
#ifdef HAVE_FSTAT
off_t filesize;
#endif
#ifdef HAVE_FSTAT
filesize = getfilesize(fp);
if (filesize > 0) {
char buf[SMALL_FILE_LIMIT];
char* pBuf = NULL;
if (filesize <= SMALL_FILE_LIMIT)
pBuf = buf;
else if (filesize <= REASONABLE_FILE_LIMIT)
pBuf = (char *)PyMem_MALLOC(filesize);
if (pBuf != NULL) {
[...]
}

SMALL_FILE_LIMIT is 1 << 14 which is roughly 16K (not that reasonable :-).
So when we enter PyMarshal_ReadLastObjectFromFile and allocate buf, we push 
around 16K on the stack, which is a lot. That's why we segfault soon after when 
we call a function (callq), there's no space left on the stack.
So there are several solutions:
- make buf static, but it would increase Python size by almost 16K
- reduce SMALL_FILE_LIMIT, or remove it altogether. I guess SMALL_FILE_LIMIT is 
there to speedup loading of small files, but I'm not sure that malloc() would 
incur an important overhead
- reading the whole file to memory sounds weird, we sould probably be using 
mmap() here

Peers ?

--
nosy: +neologix

___
Python tracker 

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

[issue8355] diff.py produce unified format by default


Benjamin Peterson  added the comment:

-1 Even if diff.py is not exaclty a diff replacement, it still makes sense to 
emulate what's in people's minds. I really don't find having to type 3 more 
characters a very convincing argument.

--
nosy: +benjamin.peterson
status: open -> closed

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


STINNER Victor  added the comment:

See also issue #8429.

--

___
Python tracker 

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

[issue8429] buildbot: test_subprocess timeout