Charles-François Natali added the comment:
And here's the test.
To sum up:
- reinit_tls.diff makes sure to call PyThread_ReInitTLS() at the beginning of
PyOS_AfterFork(), so that the TLS API is usable within PyOS_AfterFork() (e.g.
in _after_fork()). It would be applied to 3.2 and de
Changes by Charles-François Natali :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Charles-François Natali added the comment:
I've reverted the commit.
--
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python tracker
<http://bugs.pyt
Charles-François Natali added the comment:
> Given that, flistdir() and fwalk() seem like the most consistent choices of
> name for APIs that aren't directly
> matching an underlying POSIX function name.
Well, that seems OK for me.
I guess the only reason fdlistdir() is nam
Charles-François Natali added the comment:
It's to mimic os.walk()'s behavior:
http://hg.python.org/cpython/file/bf31815548c9/Lib/os.py#l268
--
___
Python tracker
<http://bugs.python.o
Changes by Charles-François Natali :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue13817>
___
___
Python-bugs-list mai
Charles-François Natali added the comment:
Here are two new versions, both addressing Antoine's and Nick's comments:
- fwalk-3.diff is just an updated version
- fwalk-single_fd.diff doesn't use more than 2 FDs to walk a directory
tree, instead of the depth of directory tree. It&
Charles-François Natali added the comment:
> I think the O(depth) version is fine. The O(1) version is quite more
> complicated, difficult to follow, and it seems less robust (it doesn't
> use try/finally and therefore might leak fds if the generator isn't
> exhausted
Charles-François Natali added the comment:
I thought about this a bit more, and I realized that a slight variation
of this bug also affects 2.7, and also older versions (i.e. before
_PyGILState_Reinit() was introduced), because any code that gets called
from PyOS_AfterFork() and uses the TLS
Charles-François Natali added the comment:
Committed.
Christoph, thanks for the report.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
It's a duplicate of issue #12157.
--
nosy: +neologix
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> join method of multiprocessing Pool object hangs if iterable
argument of
Charles-François Natali added the comment:
> Well it would probably be closed when the connection object is
> destroyed, but the patch looks ok anyway.
Let's be nice with those non refcount-based implementations out there :-)
What do you think of the patch attached
(connection_mult
Charles-François Natali added the comment:
This broke a sparc buildbot:
"""
==
FAIL: test_alaw2lin (test.test_audioop.TestAudioop)
--
Traceba
Charles-François Natali added the comment:
"""
for x in [0.05, 0.04, 0.03, 0.02, 0.01]:
z = scheduler.enter(x, 1, fun, (x,))
"""
Since the test uses relative times, if the process is preempted more than 0.01s
between two calls to enter (or if the clock goes
Charles-François Natali added the comment:
Committed, thanks for the comments.
Note to myself (and others that might be interested in the O(1)) version):
we can't simply call openat(dirfd, "..", O_RDONLY) to re-open the current
directory's file descriptor after having walk
Charles-François Natali added the comment:
Closing, since it's hard to write correctly, and apparently not that useful.
--
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http:
Charles-François Natali added the comment:
Closing (see http://bugs.python.org/msg149904 and
http://bugs.python.org/msg149909).
--
assignee: docs@python ->
resolution: -> rejected
stage: patch review -> committed/rejected
status: open -> closed
versions: -Python 2.7
Charles-François Natali added the comment:
> However, let me point out the following sentence:
> “Ports without SO_EXCLUSIVEADDRUSE set may be reused as soon as the socket on
> which bind was previously called is closed.”
>
> ...which seems to suggest we shouldn't us
Charles-François Natali added the comment:
> I think you read it wrong.
Duh, I managed to misread both the comment and the code :-)
What my subconscious refused to admit is the fact that on Windows, SO_REUSEADDR
allows you to bind to any port - even though the other application didn&#x
Charles-François Natali added the comment:
Here's another failure due to the same type of race:
"""
==
FAIL: test_queue (test
Charles-François Natali added the comment:
Here's a trivial patch.
I run the testsuite on one of the Windows buildbots, and there was one failure,
in test_concurrent_futures:
"""
==
FAIL: test_
Charles-François Natali added the comment:
Committed to default.
I won't backport it to other branches, since it's more of a feature request
than a bug fix.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Pyt
Changes by Charles-François Natali :
--
keywords: +needs review, patch
stage: -> patch review
Added file: http://bugs.python.org/file24468/importlib_replace.diff
___
Python tracker
<http://bugs.python.org/issu
Changes by Charles-François Natali :
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13961>
___
___
Python-bugs-list mailing list
Unsubscribe:
Charles-François Natali added the comment:
"""
OSError: [Errno 16] Device or resource busy:
'/nfs/tmp/pymp-f7R9S6/.nfse039692f0236'
"""
That's because the temporary directory is removed while a file inside is still
open.
And tha
Charles-François Natali added the comment:
The crash occurs in an oject's destructor.
Are you using any third-party module (lsof/pmap can help)?
Also, it'd help if you tried reproducing the crash with a debug build
(./configure --with-pydebug && make).
Charles-François Natali added the comment:
> Possibly a double free?
> (gdb) p *op
> $5 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x3c6d9f0}
>
It indeed looks like a double free (see the previous and next pointers
have already been set to NULL).
Could you chec
Charles-François Natali added the comment:
(I'm adding Antoine to the noisy list).
You could maybe try building with '--without-pymalloc', and run under valgrind
(--suppressions=Misc/valgrind-python.supp), see
http://hg.python.org/cpython/file/6653328a02d0/Misc/
Charles-François Natali added the comment:
> Unfortunately, my application is running so slow under valgrind that
> behavior is changing, namely the sockets are all timing out.
Did you see any invalid read/write?
By the way, a google search returned me this:
https://github.com/pa
Charles-François Natali added the comment:
SimpleXMLRPCRequestHandler.do_POST() is simply looping on EOF.
The patch attached fixes this (the server doesn't seem to generate an error in
response to this partial request though).
--
keywords: +patch
nosy: +neologix
Added file:
Charles-François Natali added the comment:
I'm running out of ideas to debug this, maybe Antoine or Amaury can help :-)
One last idea (not sure it will work though):
If Channel's finalizer gets called twice, inside Channel.__del__, you
could save a string representation of t
Charles-François Natali added the comment:
With test.
test_xmlrpc has a timeout detection code which is simply broken (and it's
actually documented): I just removed it, so if the server loops, the test will
block. I think it's acceptable since other tests behave in the same way,
Charles-François Natali added the comment:
Well, it's not really needed, as long as scheduler deals correctly
with expired deadlines.
--
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
The test fails on 2.6 and 2.7, because of a EPIPE, which is normal in
this case (well, at least expected):
"""
test_partial_post (test.test_xmlrpc.SimpleServerTestCase) ...
Exception happened du
Changes by Charles-François Natali :
--
stage: patch review -> commit review
___
Python tracker
<http://bugs.python.org/issue13961>
___
___
Python-bugs-list mai
Charles-François Natali added the comment:
Should be fixed now, thanks.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
I'm closing, since the manager should be shutdown (and TMPDIR on NFS isn't a
good idea).
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
type: crash -> behavior
Charles-François Natali added the comment:
As noted by Antoine somewhere else (don't remember if it was on the bug tracker
or mailing list), most of the startup time is due to site import:
"""
cf@neobox:~/python/cpython$ time ./python -c ''
[44249 refs]
real
Charles-François Natali added the comment:
Committed, thanks!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> Two others seem to be the internal "bootstate" structure used to
> run thread objects (daemon threads?).
Even for daemon threads, since the boostate structure is freed when
the thread's run() method returns, this shouldn'
Charles-François Natali added the comment:
> Here is an initial implementation.
Wouldn't it be simpler with a mp.Condition?
Otherwise, this should be added to Lib/multiprocesing.synchronize.py, and the
tests to test_multiprocessing.
--
nosy: +
Charles-François Natali added the comment:
> I am proposing the following patch to have a better unique
> filename:
It's unneeded, O_EXCL ensures the file won't be corrupted.
It's actually a regression introduced by de6703671386. My bad.
Here's a patch.
--
k
Charles-François Natali added the comment:
> But is there still a reason to use id(path) then?
IIRC, the reason is to avoid having a stale pyc file indefinitely in
case of crash:
if we always used, let's say, path + '.tmp', if the process crashes
before the rename, then all s
Charles-François Natali added the comment:
> But that will also fail if id(path) happens to be fairly
> deterministic
Well, if you always get the same id(path), then yes, but I really doubt it,
especially with CPython where it's the object's address (I guess there's the
Charles-François Natali added the comment:
I've committed the fix.
As for improving the randomness of the temporary file name, I'm not against it
(I'm just not convinced it's necessary).
--
resolution: -> fixed
stage: commit review -> committed/rejec
Charles-François Natali added the comment:
"""
File
"/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/test_zlib.py",
line 96 in test_big_buffer
"""
The SIGBUS could be due to the buildbot running o
Charles-François Natali added the comment:
> but maybe it's due to something specific about the configuration of the
> buildbot
> machine?
Maybe you didn't try with a large enough file. Here's a trial on my box:
"""
$ df -h /tmp/
Filesystem
Charles-François Natali added the comment:
In test/test_multiprocessing.py:
"""
def test_waitfor(self):
[...]
with cond:
result = cond.wait_for(lambda : state.value==0)
self.assertTrue(result)
self.assertEqual(state.value, 0)
Charles-François Natali added the comment:
I'm also in favor of adding extended attributes to copy2:
"""
Similar to shutil.copy(), but metadata is copied as well
"""
extended attributes are metadata. And there a
Charles-François Natali added the comment:
> +1 to Antoine’s proposal of removal.
Agreed.
Here's a patch.
Do note, however, that it's a behavior change: the address_string()
method is documented to return a resolved hostname (when possible).
--
keywords: +needs revie
Charles-François Natali added the comment:
> - os.realpath() uses canonicalize_file_name() if available, or use
> realpath() with a buffer of MAXPATHLEN bytes
MAXPATHLEN is not necessarily defined (e.g. on the Hurd): if it's not
defined, it is set either to MAX_PATH (if it&#
Charles-François Natali added the comment:
"""
Thread 0x2ba588709700:
File
"/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/test/support.py",
line 1168 in consumer
File
"/var/tmpfs/martin.vonloewis/3.x.loewis-parallel2/build/Lib/threadin
Charles-François Natali added the comment:
> 1. IIUC, the goal of the watchdog thread is to collect memory
> consumption in a timely manner: that's now the case, but since the
> information is printed in a standard thread, it doesn't bring any improvement
> (because
Charles-François Natali added the comment:
> I think my original plan was to put it in non-blocking mode, but I
> must have forgotten in the end.
Here's a patch.
> I can't think of any drawback off the top of my head, so that sounds
> reasonable.
I'll try to wr
Charles-François Natali added the comment:
> The behaviour under Gtk.main() should be changed to respond to the
> KeyboardInterrupt.
Well, you should report that to (Py)GTK folks then :-)
Either they set up a SIGINT handler, or they catch the KeyboardInterrupt
exception, but that&#
Charles-François Natali added the comment:
@Narnie
This is the Python bug tracker, not the PyGTK one.
You should report your problems on the PyGTK/GTK bug tracker.
Thanks.
--
nosy: +neologix
resolution: -> invalid
stage: -> committed/rejected
status: open -&g
Charles-François Natali added the comment:
test_bigmem now passes on the buildbot:
http://python.org/dev/buildbot/all/builders/AMD64%20debian%20bigmem%203.x/builds/149/steps/test/logs/stdio
--
___
Python tracker
<http://bugs.python.org/issue14
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
Does Windows still have its once per day/week/whatever time synchronization, or
does it use a proper NTP client?
Because this offset is way too large for a broken RTC lock, so it might simply
be some process adjusting the clock behind our back
Charles-François Natali added the comment:
> I think we could close this bug because it's du to the pthread library
> on OpenBSD and not Python.
Indeed.
--
resolution: -> invalid
stage: -> committed/rejected
type: -> behavior
__
Changes by Charles-François Natali :
--
resolution: -> invalid
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Charles-François Natali :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue12905>
___
___
Python-bugs-list mailing list
Un
New submission from Charles-François Natali :
As suggested in http://bugs.python.org/msg154330, here's a rewrite of the test
memory watchdog using subprocess instead of thread + faulthandler.
--
components: Tests
files: mem_watchdog_subprocess.diff
keywords: needs review,
Charles-François Natali added the comment:
> + f = open(self.procfile, 'r')
>
> 'rb' mode is enough here, no need of Unicode ;-)
Why?
At least to me, 'r' stands for text I/O, whereas 'rb' stands for
binary I/O: here, I want to read /proc//statm
Charles-François Natali added the comment:
Random thoughts:
- as noted by Antoine, it probably affects a lot of code throughout
the standard library
- sem_timedwait() (used by lock.acquire() on POSIX) is affected (the
implementation using a condition variable could use
pthread_condattr_setclock
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
I must be missing something, but I fail to see the problem here.
Basically, when SIGINT is received before the user code is run, it's caught by
the default handler which prints a traceback and exits. What's wrong with that?
Not catching SI
Charles-François Natali added the comment:
Here's a new version, with a dedicated script for the watchdog process.
--
Added file: http://bugs.python.org/file24950/mem_watchdog_1.diff
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
I think you're simply running OOM, and Linux is thrashing to death.
If you wait long enough, the process should get nuked by the OOM killer (well,
in theory).
What happens if you disable swap altogether ('swapoff -a')?
You can also c
Charles-François Natali added the comment:
> for everybody who is not *programming* python (imagine there is a *real*
> user) the tracebacks are useless. Even worse, because the error messages are
> *changing*, because of different library parts not catching the exception.
Well, I
Charles-François Natali added the comment:
> Or we could change Py_InitializeEx() to setup the signal handlers
> after having imported the site module:
Note that I don't really like this solution, because it's better to
setup handlers for fatal signals (SIGPIPE, SIGXF...)
Charles-François Natali added the comment:
Here's a patch flushing stdout explicitely (should not be necessay
unless the watchdog crashes, but...).
Also, redirect stderr to /dev/null.
--
Added file: http://bugs.python.org/file24974/mem_watchdog_2
Charles-François Natali added the comment:
I agree with Martin: we really do handle the signal, and as such, the
only way to convey the relevant information to the parent as to which
signal caused the exit would be to re-raise it, which is really ugly
and probably not a good idea.
Processes
Charles-François Natali added the comment:
>> I agree with Martin: we really do handle the signal, and as such, the
>> only way to convey the relevant information to the parent as to which
>> signal caused the exit would be to re-raise it, which is really ugly
>> and
Charles-François Natali added the comment:
> In any case, I'd appreciate, if cpython would be changed to something more
> sane/less verbose by default.
By default, certainly not.
--
___
Python tracker
<http://bugs.python.
Charles-François Natali added the comment:
And here's the full message:
"""
==
FAIL: test_6_daemon_threads (test.test_threading.
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
Since eab274c7d456, all the buildbots are randomly failing, e.g.
"""
==
FAIL: test_method_deprecations (test.test_urllib2.Open
Charles-François Natali added the comment:
Should 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:
> I'm working on figuring out the exact conditions under which it
> happens and creating a harness. I'll post it when I've got it.
Please do so, because I'm quite skeptical about waitpid() returning 0
without WNOHANG.
If y
Charles-François Natali added the comment:
> Sorry if I missed something, didn't RTFM etc.
You didn't: it's a duplicate of #10332 (which has already been fixed).
--
nosy: +neologix
resolution: -> duplicate
stage: -> committed/rejected
status: o
Changes by Charles-François Natali :
--
nosy: +pitrou
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue14087>
___
___
Python-bugs-lis
Charles-François Natali added the comment:
Tiny review.
Two more details:
- since it's relatively straightforward to cache the last value returned using
a static variable, it might be interesting to use this to make sure that the
values returned are indeed monotonic
- I'm no
Charles-François Natali added the comment:
Hello,
This has actually nothing to do with memoryview:
"""
>>> import os
[67212 refs]
>>> stdin = os.fdopen(0)
[67234 refs]
>>> del stdin
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper n
Charles-François Natali added the comment:
>> The Condition variables are canonically prone to "spurious wakeups"
>> and "stolen wakeups".
>
> No, they aren't. Just because POSIX says they are doesn't mean *our*
> condition variables are the
Charles-François Natali added the comment:
> I'm proposing the following changes to the threading docs. Most of them are
> cleanups and small improvements, but I also rewrote the offending paragraph,
> and made the wait_for example more proeminent.
Lo
Charles-François Natali added the comment:
> Therefore the expected digest changes each time.
Exactly.
Timing attacks (which aren't really new :-) depend on a constant digest to
successively determine the characters composing the digest. Here, that won't
work, because the d
Charles-François Natali added the comment:
This stack trace is strange.
Is it really the python binary?
Anyway, if it's segfaulting inside dlmalloc, there's probably not much we can
do.
Actually, I wonder why we still ship it...
--
nosy: +neolog
Changes by Charles-François Natali :
--
nosy: +haypo
status: open ->
___
Python tracker
<http://bugs.python.org/issue14532>
___
___
Python-bugs-list mai
Changes by Charles-François Natali :
--
status: -> open
___
Python tracker
<http://bugs.python.org/issue14532>
___
___
Python-bugs-list mailing list
Unsubscri
Charles-François Natali added the comment:
> if response == digest:
> can be replaced by:
> if sum(x^y for x, y in itertools.zip_longest(response, digest,
> fillvalue=256)) == 0:
Yeah, sure, but is it useful at all?
The digest changes at every connection attempt, so this s
Charles-François Natali added the comment:
[...]
> Disagreed. Unit tests should definitely protect against the introduction
> of bugs (willingly or not). And unpredictable behaviour is usually
> considered a bug.
>
> If you think the condition variable specification should be cha
Charles-François Natali added the comment:
I don't see the point of obfuscating the code to avoid a vulnerability
to which the code is not even vulnerable, just so that it can be used
as example...
There are *thousands* of ways to introduce security flaws, and the
Python code base if
Charles-François Natali added the comment:
> You call it obfuscating, I call it security correctness and developer
> education. Tomayto, tomahto. ;-)
Well, I'd be prompt to changing to a more robust digest check
algorithm if the current one had a flaw, but AFAICT, it's not t
Charles-François Natali added the comment:
> Given that this issue has affected a lot of security-sensitive third-party
> code (keyczar, openid providers, almost every python web service that
> implements "secure cookies" [1] or other HMAC-based REST API signatures), I
&g
Charles-François Natali added the comment:
> Ok, doc improved in 9d4109af8f3b.
LGTM.
Kristján, how about updating your patch to only fix the original
problem you spotted (notify() called before wait()), then we can see
the remaining pa
Charles-François Natali added the comment:
> I think it's bundled with our copy of libffi.
i'm not familiar - at all - with libffi.
But does it really need a bundled malloc() implementation?
> I'd be more than happy to use my own installation of libffi instead, but i
Charles-François Natali added the comment:
Hmm...
I don't really like disabling GC, because it has a process-wide side
effect, and hence isn't thread-safe: if another thread forks() or
creates a subprocess right at the wrong time, it could end up with the
GC disable
Charles-François Natali added the comment:
>> That's a problem indeed. Perhaps we need a global "fork lock" shared
>> between subprocess and multiprocessing?
>
> I did an atfork patch which included a (recursive) fork lock. See
>
> http://bugs.py
Charles-François Natali added the comment:
Hello Adi,
Thanks for your patch.
Just a detail:
"""
if platform == 'hp-ux11':
lib_dirs += ['/usr/lib/hpux64', '/usr/lib/hpux32']
"""
Wouldn't
701 - 800 of 1826 matches
Mail list logo
