Charles-François Natali added the comment:
> Can this be fixed?
More or less.
The following patch does the trick, but is not really elegant:
"""
--- a/Parser/tokenizer.c2011-06-01 02:39:38.0 +
+++ b/Parser/tokenizer.c2011-12-16 08:48:45.
Charles-François Natali added the comment:
Thanks Michael.
I committed a simpler version of your patch.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> So it seems unlikely to be the explanation.
Victor reproduced in on IRC, and it's indeed an overflow.
The problematic code is in readline_file:
"""
bigger = self->buf_size << 1;
if (bigger
Charles-François Natali added the comment:
Here's a patch which should fix this. However, I'm unable to test it.
--
keywords: +patch
Added file: http://bugs.python.org/file24006/pickle_overflow.diff
___
Python tracker
<http://bu
Charles-François Natali added the comment:
New version.
--
Added file: http://bugs.python.org/file24008/pickle_overflow-1.diff
___
Python tracker
<http://bugs.python.org/issue13
Charles-François Natali added the comment:
This broken the "Fedora without thread buildbot", since sched now requires the
threading module:
http://www.python.org/dev/buildbot/all/builders/AMD64 Fedora without threads
3.x/builds/1250/steps/test/logs/stdio
--
nosy: +neolo
Charles-François Natali added the comment:
Two patches have recently modified this part of the code:
http://hg.python.org/cpython/rev/d4d9a3e71897
http://hg.python.org/cpython/rev/cd15473a9de2
I'm unable to reproduce the problem on Linux 3.1.0 x86 with branch 2.7 (for
those who would li
Charles-François Natali added the comment:
There was a recent buildbot failure on test_lock_conflict() because of a race.
Looking at your patch, I must be missing something, but why not simply use a
multiprocessing condition to signal when the parent process has acquired the
lock?
Otherwise
Charles-François Natali added the comment:
Looking at the strace output:
Successful test:
sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\267", 1}], msg_controllen=16,
{cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0},
0) = 1
The FD sent is 7 ({7} fie
Charles-François Natali added the comment:
> But I tried building this
> http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2 and that
> build worked successfully.
This is 2.7, which is more than a year old.
The most recent 2.7 version is
http://www.python.org/ftp/python/2.7.2/Pyt
Charles-François Natali added the comment:
Alright, thanks!
--
resolution: -> out of date
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
Victor, could you try the patch attached?
--
Added file: http://bugs.python.org/file24030/threading_reinit_lock.diff
___
Python tracker
<http://bugs.python.org/issue11
Charles-François Natali added the comment:
Alright, should be fixed now.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Charles-François Natali added the comment:
Should be fixed now.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
I'm personally +1 on removing the verbose thing altogether:
- it's ugly
- I doubt it's really useful (I mean, printing to stderr - which is often line
buffered or unbuffered - upon every action will probably change the timing)
- it a
Charles-François Natali added the comment:
I think this could be due to the multiprocessing manager's server socket
backlog value, which is a little too low: by default, it's set to 5, and the
tests launch up to 3 threads and 3 processes in parallel, so if we're unlucky
with
Charles-François Natali added the comment:
> Probably because I'm a threading/multiprocessing neophyte :)
That's a very good reason :-)
Here's a version using two multiprocessing events. Note that I use
timeouts for wait() just to avoid being stuck if something goes wrong:
Charles-François Natali added the comment:
Should be fixed now, thanks!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
Another failure on an OpenIndiana buildbot:
"""
==
ERROR: testTimeoutConnect (test.test_ftpl
Charles-François Natali added the comment:
As I said, I'm skeptical about the benefit vs maintenance burden ratio,
especially since cPython doesn't target performance critical applications. I
just fear that's a lot of intrusive code which will only be used by a handful
of p
Charles-François Natali added the comment:
> 1. On FreeBSD, we must assume that every blocking system call, in
> *every thread*, can be interrupted, and we need to catch EINTR.
That's true for every Unix. Every blocking syscall can return EINTR, and there
are may non restartab
Charles-François Natali added the comment:
Looks good to me, except for another minor nit:
"""
the elements of the `iterable` are expected to be tuples
"""
AFAICT, you just require the elements of `ìterables` to be iter
Charles-François Natali added the comment:
> a struct timespec providing theoretical nanosecond precision.
Indeed. EXT3's timestamps have a 1s granularity, for example.
Another possibility would be to store both mtime and st_size (it's the default
heuristic used by rsync d
Charles-François Natali added the comment:
Thanks for the patch sbt.
I think this is indeed useful, but I'm tempted to go further and say we should
make this the default - and only - behavior. This will probably break existing
code that accidentaly relied the fact that the implementation
Charles-François Natali added the comment:
I'd like to make this move forward.
Milko, I see you have an implementation which looks OK at a first glance. Would
like to propose a patch against the default branch? The patch should include
documentation and tests.
I'm not sure abou
Charles-François Natali added the comment:
> There is probably lots of such code:
> I'm not convinced about making it the default behaviour, and
> certainly not the only one.
Then I'm not convinced that this patch is useful.
Having three different implentations and code
Charles-François Natali added the comment:
Yes, but it's not easy: the different URLs provided don't demonstrate
the behavior anymore (even if we do find such an URL, there's no
guarantee it won't change in a couple days/weeks).
It could be possible to set up an ad-hoc
Charles-François Natali added the comment:
> I prefer to write a "best-effort" function
I disagree. People who explicitely use an atomic file API want
atomicity/persistency, otherwise they wouldn't use it. Exposing a function that
may, or may not, be atomic is just plai
Charles-François Natali added the comment:
Here's a new version with a test (untested).
Note that I'm absolutely not sure that the 'memsize' argument to
bigmemtest is correct.
--
Added file: http://bugs.python.org/file24079/pi
Charles-François Natali added the comment:
Victor, could you try the attached script on FreeBSD, to see if you get
ECONNREFUSED?
--
___
Python tracker
<http://bugs.python.org/issue13
Charles-François Natali added the comment:
I assume this was due to the following bug:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/259219
http://lists.freedesktop.org/archives/mesa-dev/2011-March/006180.html
In short, MESA didn't use the correct TLS model for thread-local vari
Charles-François Natali added the comment:
> I adhere to "flat is better than nested". e.g. it always irks me to type
> "urllib.request" instead of "urllib".
Well, that's what (selective) imports are for, no ?
from urllib import re
Charles-François Natali added the comment:
> Does it have to be a class? What would be the operations apart from
> write()?
Well, I thought that making it a file-like object could be useful:
that way, one could pass it to pickle.dump(), logging.StreamHandler or
any method expecting a fil
Charles-François Natali added the comment:
> If you want atomicity to apply to logging,
> you must instead guarantee the durability of each write() call, meaning
> calling fsync() on each logging call
Why so?
There's no point in calling fsync() after each write, since data i
Charles-François Natali added the comment:
Thanks for your patches, David.
I've only applied the first one: looking at the second one, I don't think they
are really problems (-Wstrict-aliasing=2 is know for generating a lot of false
positives).
--
nosy:
Charles-François Natali added the comment:
> Ah, it's a temporary file indeed.
> But does that mean you can't inspect your logs in real time? All log
> files I have ever seen are available under their final name while they
> are still being written to.
>
Yes, l
Charles-François Natali added the comment:
I'd prefer an optional flag to rename() too.
I really don't like having different functions that achieve the same thing.
It's not obvious to infer from 'replace' its real intent, since it
doesn't match any standard syscall
Charles-François Natali added the comment:
> How about overwrite=[None, True] with None meaning "OS default"?
+1.
> One of the Python advantages is providing predictable cross-platform
> behavior. If we can't introduce nice API without BC break, it is not
> a r
Charles-François Natali added the comment:
> I propose quite the opposite. rename() should not overwrite existing
> files by default.
1. That's not what I understood from:
> os.rename(overwrite=True) to produce consistent cross-platform
> behavior.
2. The above arg
Charles-François Natali added the comment:
> Yes, I get a ECONNREFUSED. I tested backlog.py on FreeBSD 8.2.
Thanks.
I bumped the backlog, I hope it will fix this.
We can leave this report open for a couple days, to see how the buildbots
beh
Charles-François Natali added the comment:
IIUC, the deadlock avoidance code just checks that acquiring a
per-module lock won't create a cycle.
However, I think there's a race, because the cycle detection and the
lock acquisition is not atomic.
For example, let's say we have a
Charles-François Natali added the comment:
> That's true. Do you think temptatively acquiring the lock (without
> blocking) would solve the issue?
I think it should work. Something along those lines:
while True:
if lock.acquire(0):
lock.tstate = tstate
return Tr
Charles-François Natali added the comment:
Seems to be fixed now.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> This change probably should be backported to 3.2 branch.
I'm not sure about this, I don't feel comfortable backporting a such
path which doesn't solve a "real world problem".
--
_
Charles-François Natali added the comment:
The patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue13645>
___
___
Python-bugs-list mailin
Charles-François Natali added the comment:
Alright, it seems to be fixed.
We can still reopen if this happens again.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
That's because SocketListener uses SO_REUSEADDR.
It seems that, with SO_REUSEADDR, Windows allows binding to a port even though
there's a socket already bound to the same port in the LISTEN state: this is
wrong, the semantics of SO_REU
Charles-François Natali added the comment:
Should be fixed now.
Vilmos, thanks for the patch!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Charles-François Natali added the comment:
The core of the problem is that we don't just want those methods to be atomic
or thread-safe, but reentrant (or rather async-safe).
As such, protecting by a lock isn't enough (and it's not really feasible in
Python).
Note
Charles-François Natali added the comment:
OK, so just removing SO_REUSEADDR on Windows should do the trick...
Seriously, why can't they simply conform to existing standards :-(
If someone wants to provide a patch + test, go ahead!
--
___
P
Charles-François Natali added the comment:
> That sounds like a good solution in the middle-term. Are there any
> drawbacks? (apart from launching a thread)
Just to be clear: the approach I was suggesting is to have a resident
thread dedicated to signal management, not to spawn a new on
Charles-François Natali added the comment:
I've done a small review.
--
___
Python tracker
<http://bugs.python.org/issue12760>
___
___
Python-bugs-list m
Charles-François Natali added the comment:
> If the above gets solved on windows my problem will just go away, thanks
Would you like to propose a patch with test?
--
___
Python tracker
<http://bugs.python.org/iss
Charles-François Natali added the comment:
> Hmm, but that would break single-threaded programs which expect their
> select() (or other) to return EINTR when a signal is received (which is
> a perfectly valid expectation in that case).
Yes, that's why I said "that"s ano
Charles-François Natali added the comment:
> Like I said, I dont know much about named pipes and im not even sure thats
> how they are intended to work in this context. IE: if one process is
> listening, can another listen on that named pipe as well?
Under Unix, you'd get a EAD
Charles-François Natali added the comment:
Antoine, could you test the last version (test_pickle and if possible
with the OP testcase)?
I can't test it myself (32-bit machine with 1 GB).
--
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
Alright, Nick agreed on python-dev to remove the logging hack.
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue13
Charles-François Natali added the comment:
I noticed that if bind() fails (in this case with EADDRINUSE), the
socket isn't closed (FD leak).
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file24163/connection_
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Charles-François Natali :
Commit 57295c4d81ac879dd2d804190b38b2e91f934acd broke Windows buildbots:
"""
==
ERROR: test_rotator (test.test_logging.Rotating
Charles-François Natali added the comment:
I intend to commit this patch within a couple days (unless anyone objects of
course).
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issu
Charles-François Natali added the comment:
Here's a possible walkfd() implementation.
Example:
"""
$ cat /home/cf/testwalkfd.py
import os
import sys
topfd = os.open(sys.argv[1], os.O_RDONLY)
for rootfd, dirs, files in os.walkfd(topfd):
print(rootfd, dir
New submission from Charles-François Natali :
After a call to fdlistdir(), another call to fdlistdir() on the same file
handle (but using a different FD, since the FD passed to fdlistdir() is closed)
will return an empty list:
"""
$ cat ~/test_fdlistdir.py
import os
import sys
Charles-François Natali added the comment:
Here's a new version of the patch that should address all the comments.
--
Added file: http://bugs.python.org/file24179/open_create_x-3.patch
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
> For some reason, the second changeset broke the OpenIndiana buildbots:
>
I have absolutely no idea of why this doesn't work. I suspect
rewinddir() is a noop on OpenIndiana if readdir() hasn't been called.
I'll revert this comm
Charles-François Natali added the comment:
Here's a patch addressing the multiple bind() problem on Windows.
Note that this problem also affects other parts of the stdlib, which use
SO_REUSEADDR when available.
Also, there's an rather confusing comment in support.find_u
Charles-François Natali added the comment:
> Just a small note: FileExistsError is raised, not exactly OSError,
> when the file exists.
I've updated the doc accordingly.
--
stage: patch review -> commit review
___
Python
Charles-François Natali added the comment:
> Hmm, sorry, I must have misremembered. I thought openat didn't follow
> symlinks.
OK, I was afraid I had missed something.
> As for the patch, I think there's a problem with the API
Yes, it was really a proof-of-concept, the
Charles-François Natali added the comment:
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xd6aa)[0x7fbd27c806aa]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0xde51)[0x7fbd27c80e51]
/usr/lib/python2.7/dist-packages/psycopg2/_psycopg.so(+0x13f9b)[0x7fbd27c86f9b]
/usr/lib
Charles-François Natali added the comment:
> I'll try Python 2.6, but this says 2.7 is supported
(OOps, mixed up psyco and psycopg).
Anyway, if you look at the backtrace, you'll see it segfaults inside psycopg.
You should report this crash to this project.
Closing.
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Charles-François Natali :
Commit 190ad17f5a87481a006434a2a3d3a8e1e954a6db broke the fedora
without-threads buildbot:
"""
./python ./Tools/scripts/run_tests.py -j 1 -u all -W --timeout=3600
Traceback (most recent call last):
File "/home/buildbot/build
Charles-François Natali added the comment:
Committed.
David, thanks for the patch!
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Charles-François Natali :
os.fdlistdir() closes the FD passed as argument.
This is annoying, since in 99% of the cases you'd like to keep FD intact, so
you end up doing os.fdlistdir(os.dup(fd)).
Here's a patch that duplicates the FD in fdlistdir(), so that the o
Charles-François Natali added the comment:
Nick suggested to call the new flag "exclusive create" in the doc (and explain
in whatsnew that it's based C11 new 'x' flag).
Could someone please check the attached patch?
My wording sounds really clumsy, so I'd pr
Charles-François Natali added the comment:
Thanks!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
Here's a patch with tests and documentation.
I noticed something surprising:
walk() with followlinks=False returns links to directories as
directories (in dirnames).
I find this surprising, since if you don't follow symlinks, those are
just
Charles-François Natali added the comment:
Here's an updated version.
Note that I'm not pushing towards changing the current behavior
pertaining to symlinks to directories, because if we change this, this
will break code.
For example to count the number of lines of all the fil
Charles-François Natali added the comment:
I must be missing something, but how is raising an exception when a collision
threshold is reached a good thing?
Basically, we're just exchanging a DoS for another (just feed the server
process with ad-hoc data and he'll commit suicide).
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file24176/walkfd.diff
___
Python tracker
<http://bugs.python.org/issue13734>
___
___
Python-bug
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file24197/fdwalk.diff
___
Python tracker
<http://bugs.python.org/issue13734>
___
___
Python-bug
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file24202/fdwalk-1.diff
___
Python tracker
<http://bugs.python.org/issue13734>
___
___
Python-bug
Changes by Charles-François Natali :
Added file: http://bugs.python.org/file24211/fdwalk-2.diff
___
Python tracker
<http://bugs.python.org/issue13734>
___
___
Python-bug
Charles-François Natali added the comment:
> I was scared by the note in the documentation and wondered if the
> socket Python API was completely incapable of handling half-closed
> connections cross platform.
[...]
> It makes it half-closed as it should
Indeed. Calling shut
Charles-François Natali added the comment:
I've committed the patch to 3.3.
Since the documentation aspect is traced in Issue #12103, I'm closing this
issue.
Марк, thanks for reporting this!
--
resolution: accepted -> fixed
stage: commit review -> committed/rejec
Charles-François Natali added the comment:
> And apparently some buildbot doesn't like it
Linux-2.6.22-vs2.2.0.7-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-2.0.1
little-endian
O_CLOEXEC support was added to Linux 2.6.23: this means that the libc defines
it while th
Charles-François Natali added the comment:
The real issue is that the libc defines O_CLOEXEC, but kernels prior to 2.6.23
don't support it: instead of returning EINVAL, the socket syscall silently
ignores the flag (don't know why I made the comment about this flag being
de
Charles-François Natali added the comment:
> Oh, Linux 2.6.27+ has a SOCK_CLOEXEC option:
It's not exactly the same thing.
We want to close the socket right after fork, not wait until exec (in the OP
case there was no exec).
> Patch looks fine to me. Is it easily testable?
Charles-François Natali added the comment:
> This is a kernel bug, not a bug in the GNU libc (ask Ulrich if you are not
> sure ;-)).
Kernels prior to 2.6.23 didn't know about the O_CLOEXEC flag: to catch this
kind of problem, every syscall would have to check every bit when it
Charles-François Natali added the comment:
Do we really need to expose a such Linux-centric and sparingly used
function to the platform module?
Since it's needed by several tests, why not add it to Lib/test/support.py?
That way, we could also make it return a tuple without breaking any
exi
Charles-François Natali added the comment:
Antoine, do you think we can commit this as-is (i.e. without specific test)?
If yes, to what branches (I'm not really sure of what kind of change is allowed
for each branch, is there a document somewhere detailing the official p
Charles-François Natali added the comment:
@Victor
Since linux_version() won't be added to the platform module, could you add it
to test.support so that it can be used in the O_CLOEXEC test?
--
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
Checking the kernel version did the trick, the test now run fines on the
buildbots.
Thanks Victor.
Re-closing.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Charles-François Natali added the comment:
> New changeset f8c49a930015 by Victor Stinner in branch 'default':
> Issue #8407: The signal handler writes the signal number as a single byte
> http://hg.python.org/cpython/rev/f8c49a930015
There's a race.
If a signal is rece
Charles-François Natali added the comment:
> You change caused test_socketserver to hang. I attempted a fix, but I'm not
> sure if it's completely correct.
I'm a morron.
I don't know how I could miss this: closing the server socket is perfectly fine
in TCP, sinc
Changes by Charles-François Natali :
Removed file: http://bugs.python.org/file22045/ss_fork_close.diff
___
Python tracker
<http://bugs.python.org/issue5715>
___
___
Pytho
Charles-François Natali added the comment:
I've committed the patch to 2.7, and also to default (and only to default since
for py3k it's more of an optimization than a bug fix).
Closing.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status
Charles-François Natali added the comment:
So, SOCK_CLOEXEC is available.
Note that I don't like the idea of falling back to FD_CLOEXEC since
it's not atomic, and some people might rely on this.
Can we close this issue?
--
___
Python trac
Charles-François Natali added the comment:
Since it's a OOM issue, can we close?
--
___
Python tracker
<http://bugs.python.org/issue12071>
___
___
Pytho
Charles-François Natali added the comment:
> Well, this is apparently a feature request for socketserver.TCPServer.
Honestly, I'm not sure what this request is about.
The original request seemed to imply this should be made the default. I don't
agree, and think this should be
201 - 300 of 1826 matches
Mail list logo