Charles-François Natali added the comment:
Wouldn't it be better to add an 'ignore' option to the copy_tree() method with
an optional list of patterns to ignore instead of hardcoding '.nsfXXX' files?
This would make it possible to also skip '.hg', 'CVS
Charles-François Natali added the comment:
> I guess this is the magic in mkdir -p:
>
> mkdir("expert", 0755) = -1 EACCES (Permission denied)
> chdir("expert") = 0
> mkdir("tmp", 0755) =
Charles-François Natali added the comment:
Yes, creating the directories in a bottom-up way (i.e. '/net', '/net/prodigy',
'/net/prodigy/foo') could maybe avoid this problem.
But this is definietely an autofs bug, and there are probably many other place
Charles-François Natali added the comment:
Alright, closing for good then.
Andrew, if you want to get this fixed, you should report this to the autofs
folks, because it's definitely not a Python bug.
--
stage: -> committed/rejected
status: open -
Charles-François Natali added the comment:
> I see no evidence that this is a bug in Linux,
"""
stat("/net/prodigy", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
mkdir("/net/prodigy/tmp", 0777) = -1 EACCES (Permission denied)
""&qu
Charles-François Natali added the comment:
> I did think about using gc.collect(), but I was not sure whether it was
> guaranteed to collect everything possible if you only call it only once.
> (I know nothing about garbage collectors.)
You could use support.gc_collect()
Charles-François Natali added the comment:
It's actually a duplicate of #6085 (already fixed).
Cheers!
--
nosy: +neologix
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> Logging in BaseHTTPServer.BaseHTTPRequestH
Charles-François Natali added the comment:
> I'm closing again this issue.
>
> @neologix: Please open a new issue if you disagree with me on the definition
> of "seconds" for time.process_time().
I won't reopen, but I still disagree with your definition.
proces
Charles-François Natali added the comment:
> But at the heart of the matter, I see no benefit to exposing Python
> developers to the idiosyncrasies of poor C API design. I feel strongly that
> one way Python becomes "pythonic" is that it aims for the convenience of the
&g
Changes by Charles-François Natali :
--
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue15078>
___
___
Python-bugs-list mailing list
Unsubscribe:
Charles-François Natali added the comment:
> What's wrong with mmap? It uses list of optional arguments (`flags`,
> `prot`, `access`) and not only one `flags` argument.
Of course it does, as the mmap syscall(), since this arguments have nothing to
do with one another.
I was refer
New submission from Charles-François Natali :
Some test_subprocess tests are failing on really slow buildbots, such as the
Ubtuntu ARM one:
"""
==
ERROR: test_wait_timeout (test.test_subprocess.
Changes by Charles-François Natali :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Sporadic failure in test_socket
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> You could make the test a loop, with the timeout increasing each time through
> the loop, failing only if all tries fail. That way on faster machines the
> test will pass faster. It'll take even longer on slow machines, but th
Charles-François Natali added the comment:
I still don't like the idea of adding such a kludge to work around OS
bugs, so I'd suggest closing as won't fix.
--
___
Python tracker
<http://bugs.pyt
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Charles-François Natali :
--
versions: +Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue1522400>
___
___
Python-bugs-list mailin
Charles-François Natali added the comment:
Looks like a kernel bug.
The only thing "non-standard" the test does is let the client call
close() before the server has called accept(), but this shouldn't
result in ENOTCONN - and doesn
Charles-François Natali added the comment:
> On the other hand, fwalk also uses a lot of file descriptors. Users
> with processes which were already borderline on max file descriptors
> might not appreciate upgrading to find their os.walk calls suddenly
> failing.
It doesn'
Charles-François Natali added the comment:
It is guaranteed by libc's atexit(3), and should also be guaranteed here.
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
> Is there something else I can do to help resolve this bug ? I can help
> debugging this, but I am not sure how to proceed. I have a --with-pydebug
> interpreter stopped at the segfault in gdb.
Could you post the output of :
"&q
Charles-François Natali added the comment:
> (gdb) p op
> $12 = (PyObject *) 0x4dc7bc0
Don't you have GDB 7, to decode Python objects ?
You can check the type of the object with :
"""
p op->ob_type.tp_name
"""
>
> thread all apply bt is goi
Charles-François Natali added the comment:
I wouldn't rely on O_APPEND too much:
- it won't work on NFS, and probably other non-local filesystems
- it doesn't actually guarantee atomicity, because even though the the file
offset and the write is done with locking, there is still
Charles-François Natali added the comment:
This doesn't look thread-related:
"""
load: 0.50 cmd: python 10630 [runnable] 0.27u 13.07s 46% 10976k
load: 0.87 cmd: python 10630 [runnable] 0.27u 94.24s 98% 10976k
"""
See the huge system time?
This probably means
Charles-François Natali added the comment:
"synchronized" has the merit of reusing Java's denomination, which this
decorator intends to mimic, see
http://docs.oracle.com/javase/tutorial/essential/concurrency/syncmeth.html
Basically, synchronize works with the object/class (impl
Changes by Charles-François Natali :
--
resolution: -> duplicate
status: open -> closed
superseder: -> test_getcwd_long_pathnames (in test_posix) kills NetBSD
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
> So when calling close_request to deallocate the socket, it will
> always be waiting to read response until response data is available.
> It seems like an issue in SokcetServer.py library.
Hum, I don't see what you mean.
Even if there
Changes by Charles-François Natali :
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org/issue11866>
___
___
Python-bugs-list mailing list
Un
Charles-François Natali added the comment:
Thanks for the patches.
Note that you don't have to provide a patch for each branch, it's usually the
committer's job.
The patch looks good, but the test could be rewritten with assertRaisesRegex():
http://docs.python.org/dev/librar
Charles-François Natali added the comment:
You forgot to add an entry in Misc/ACKS.
--
___
Python tracker
<http://bugs.python.org/issue15676>
___
___
Python-bug
Charles-François Natali added the comment:
Looks like - another - OS-X bug.
What happens if you reduce the size argument when reading from the error pipe?
Try setting it to a value like 512 (minimum guaranteed PIPE_BUF):
"""
newData = os.read(errpipe_read, min(512, rSize))
&quo
Charles-François Natali added the comment:
> 1. Reduce the initial read size argument (rSize in my code snippet) from
> 1048576 (1MB, the same amount as used by subprocess.Popen._executeChild) to
> 100: the problem appears to go away (could be just red herring, though);
> t
Charles-François Natali added the comment:
> The reason I said above that those might be red-herring discoveries is this:
> if I insert a short time.sleep(0.001) delay before the outer pipe-read loop,
> the EINVAL errors don't get triggered either.
That's interesting.
So i
Changes by Charles-François Natali :
--
type: crash -> behavior
___
Python tracker
<http://bugs.python.org/issue15896>
___
___
Python-bugs-list mailing list
Un
Charles-François Natali added the comment:
> By the way, the existing code in subprocess.Popen (at least on 2.6.7) reads
> the pipe incorrectly: It doesn't loop to read all the data until EOF -- it
> only loops over EINTR until it gets a single successful os.read() call.
&g
Charles-François Natali added the comment:
> What's wrong with working around this bug by reading a smaller amount?
> How much data is there supposed to be?
Nothing, except that there are probably other places in the stdlib
where we can get bitten by this bug. Note that this should
Charles-François Natali added the comment:
> Option 1:
> Fix breakages as they are discovered at higher level (above os.read) as
> needed in places where usage semantics are known, and address the issue via
> errata documentation (i.e., "On Mac OS X, don't make individual
Charles-François Natali added the comment:
> The page also mentions a seqlock which looks interesting to me as
> it's fast for few writers with lots of readers.
A seqlock is suitable for consistent views of simple data structures (e.g. a
counter in the Linux kernel), but it won&
Charles-François Natali added the comment:
> I would not say that is a bug, but there is a write(wakeup_fd) call
> with ignored return code and maybe this can be improved to an output
> to stderr, or maybe a better solution.
The problem is that it's called from the signal handl
Charles-François Natali added the comment:
> since Antonie mentioned Py_AddPendingCall I came up with a patch describing
> what he proposed.
>
> Let me know if this patch can be improved or discarded(if the problem
> requires a more sophisticated solution). In case of improve
Charles-François Natali added the comment:
> I agree with Felipe that issues here can be difficult to diagnose. For
> example the fd could get mistakingly closed, but the write() EBADF would then
> be ignored and the expected signal wakeups would be lost.
Yeah, but it's a
Charles-François Natali added the comment:
> A signal handler can be called anymore, anywhere. How do you handle such
> exception in an application? "handle": do something better than exit the
> apllication.
Well, chances are you won't, but failing with an explicit erro
Charles-François Natali added the comment:
>> Why limit to EBADF? You could also have EPIPE, EINVAL and many other errors.
>> The only error you may not want to report is EAGAIN.
>
> Charles,
> You're right! If all errno cases get covered in the patch, will It looks
Charles-François Natali added the comment:
> You mean retry one time or until success?
Until success.
It should also come with a test.
--
___
Python tracker
<http://bugs.python.org/issu
Charles-François Natali added the comment:
> Please consider the attached patch and see if it solves the issue.
The patch looks OK (although I'd prefer a BSD errno example, such as
ECONNRESET, instead of a winsock one).
We should also update the documentation that states that in finish
Charles-François Natali added the comment:
> Hmm... I guess maybe we should trap all OSErrors after all (and print the
> error when in verbose mode).
Yes.
--
___
Python tracker
<http://bugs.python.org/i
Charles-François Natali added the comment:
> After the blog post, Mathew, Sandeep from HP asked how to help:
It was more than a year ago.
Has something actually be done?
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/issu
Charles-François Natali added the comment:
> Are you referring to the comment where I mention ECONNABORTED? That is a
> regular unix error (windows version is WSAECONNABORTED).
> This error occurs when the local stack decides to kill the connection, as
> opposed to ECONNRESET whi
Charles-François Natali added the comment:
> This is more or less a duplicate of #15833
Indeed, closing as duplicate.
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> most failures to write byte-compiled file no longer
Charles-François Natali added the comment:
We should probably catch all OSErrors, and log a warning in verbose mode, as
suggested by Antoine.
Catching individual errnos is tedious and error-prone.
--
nosy: +neologix
___
Python tracker
<h
Charles-François Natali added the comment:
Here's a patch.
--
Added file: http://bugs.python.org/file27469/import_error.diff
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
Roumen, are you sure you submitted your patch to the right issue?
--
___
Python tracker
<http://bugs.python.org/issue15
Charles-François Natali added the comment:
> Yes .
> Charles, lest assume that all other issues with build system, are resolved
> and source tree is ready for use. So in this situation I could run python , I
> could build all and I could run tests with an additional patc
Charles-François Natali added the comment:
> The bug is not only wget-specific. It was discovered while making APT proxy,
> so at least Debian APT fetcher has the same problem.
Debian uses wget.
--
___
Python tracker
<http://bugs.p
Charles-François Natali added the comment:
>> The bug is not only wget-specific. It was discovered while making APT proxy,
>> so at least Debian APT fetcher has the same problem.
>
> Debian uses wget.
I meant apt-get uses wget.
--
Charles-François Natali added the comment:
wget trace:
Here a 404 is treated correctly:
"""
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(4242),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
select(6, NULL, [5], NULL, {900, 0})
Charles-François Natali added the comment:
According to http://tools.ietf.org/html/rfc2616#section-8.1,
persistent connections are default in HTTP 1.1.
However, here's what's said about the persistence negotiation:
"""
An HTTP/1.1 server MAY assume that a H
Charles-François Natali added the comment:
> Charles-François's patch looks ok to me. I don't know if this warrants adding
> a test.
Yes, and triggering a failure other than a permission error (which is
probably already tested) can be difficult.
I'm abroad and won't
Charles-François Natali added the comment:
Ping.
Like Raymond, I think there's no reason to leave ambiguity in 2.7 and 3.2, so
this doc patch is probably worth backporting.
--
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
That's normal.
You're truncating the file after having it mapped, so touching the pages
corresponding to the truncated part of the file will result in a segfault.
See mmap's man page:
"""
Use of a mapped regi
Charles-François Natali added the comment:
No, it's not.
That's why I think there's nothing that can be done.
--
___
Python tracker
<http://bugs.pyt
Charles-François Natali added the comment:
> I think, handling the signal would do.
You can't.
Handling a signal like SIGSEGV or SIGBUS in any other way that exiting
the process will result in an infinite loop (as soon as the signal
handler returns the faulty instruction will be re-
Charles-François Natali added the comment:
> You can use file locks to be protected against such race condition.
> See for example:
Those are advisory locks, not mandatory locks.
It's possible to do some mandatory locking on some systems, but on every file,
and it
Charles-François Natali added the comment:
> I know how to avoid the problem in my case, the bug does not really affect
> me. I posted it because I thought that the possibility to crash the
> interpreter is something to be avoided at all costs.
I fully agree with you.
However,
Charles-François Natali added the comment:
>> You can't use longjmp from signal handlers. Well, you can, but 99% of the
>> code that does it is broken, because you can only call async-safe functions
>> from within a signal handler, and certainly can't run the int
Charles-François Natali added the comment:
> SIGBUS as well as SIGFPE or SIGSEGV is a synchronous signal. It is delivered
> to the thread that caused the trouble and the stack contents is well defined.
Except that signal handlers are per-process, not per thread.
So if another thread
Charles-François Natali added the comment:
> Charles' patch applied in 3.3 and merged to 3.x. Thanks Charles.
Thanks for taking care of this!
--
___
Python tracker
<http://bugs.python.org
Charles-François Natali added the comment:
See also http://bugs.python.org/issue14635.
This problem affects any single use of select(): instead of using an ad-hoc
wrapper in each module, it would probably make sense to add a higher level
selector class to the select module which would fallback
Charles-François Natali added the comment:
>> This problem affects any single use of select(): instead of using an
>> ad-hoc wrapper in each module, it would probably make sense to add a
>> higher level selector class to the select module which would fallback on
>> the
Charles-François Natali added the comment:
> No automated testing included because I'm not entirely sure how to replicate
> this without eating up a ton of ram or doing something naughty with ulimit.
Simply use RLIMIT_NPROC, from a subprocess:
"""
$ cat /tmp/tes
Charles-François Natali added the comment:
Also, I didn't check, but if the problems also occurs on execve()
failure, then it's much simpler: simply call Popen() with an
invalid/nonexisting executable.
--
___
Python tracker
<http://bu
Charles-François Natali added the comment:
> The problem with using RLIMIT is that the testsuite could be executing
> several tests in parallel using independent threads, for instance. You don't
> want to influence unrelated tests.
That's why I suggested to run it in a
Charles-François Natali added the comment:
Well, the first difference that jumps out is that with python 2.7, the protocol
used is SSLv2, whereas it's bare SSL on Python 3.3.0.
But another interesting thing is the presence, in Python 2.3, of many
extenstions (elliptic_curves, hear
Charles-François Natali added the comment:
> Schools put a priority on English but not on native languages. Languages must
> be preserved because they contain culture
Of course, but the main goal of a language is to communicate.
As it stand, English is the language which is the most lik
Charles-François Natali added the comment:
It's a little too vague :-)
You should probably report this on pysnmp mailing list.
If you want to debug this, you should perform a tcpdump/wireshark capture while
running your script, and see what happens (according to your description, it
Charles-François Natali added the comment:
It might be a different test triggering the buffer overflow, but the underlying
cause is the same as #20937.
--
nosy: +neologix
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> test_so
Charles-François Natali added the comment:
Could you regenerate it without --git (it doesn't show under the review
tool)?
--
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
Vinay, your change just reverted this: http://bugs.python.org/issue20065
Basically, AF_CAN being defined doesn't imply that CAN_RAW is defined.
So compilation will now fail - again - on those hosts.
--
status: closed -&
Changes by Charles-François Natali :
Added file: http://bugs.python.org/file34535/devpoll3_try_again.diff
___
Python tracker
<http://bugs.python.org/issue18931>
___
___
Charles-François Natali added the comment:
> Are you saying that an additional clause for CAN_RAW being defined should
be added around where it is used? Would that sort things out?
Yes.
> I'd rather not just revert my change, as that would mean I couldn't
compile the SSL modu
Charles-François Natali added the comment:
> That AF_CAN was undefined (even though HAVE_LINUX_CAN_H is). This is on
Ubuntu Jaunty, which I use for my Python core development.
How dear...
The latest change should be OK.
--
___
Python tracker
&l
Charles-François Natali added the comment:
I don't see anything wrong with the code.
Could you try running the test under valgrind.
You must build Python with --with-valgrind, and then:
valgrind --tool=memcheck --suppressions=Misc/valgrind-python
New submission from Charles-François Natali:
The title says it all: in Modules/hashtable.c, the macro name is
_PY_HASHTABLE_ENTRY_DATA instead of _Py_HASHTABLE_ENTRY_DATA.
Should this be fixed in 3.4?
--
components: Extension Modules
messages: 214570
nosy: haypo, neologix
priority
Changes by Charles-François Natali :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Charles-François Natali added the comment:
It's a duplicate of issue #18596, which has already been fixed.
Jeffrey, when you report an issue, please check with the latest version.
Thanks!
--
nosy: +neologix
resolution: -> duplicate
stage: -> committed/rejected
status: ope
New submission from Charles-François Natali:
Adding a compile option to build with ASAN
(https://code.google.com/p/address-sanitizer) could allow us to catch many
memory-related errors (stack/buffer overflows, etc).
Of course, the second step would be to setup buildbots to use this flag
Charles-François Natali added the comment:
Note that ASAN will interfere with the faulthandler's module (since it sets up
its own signal handlers), so if we were to incorporate it into the test suite,
that's something we should
Charles-François Natali added the comment:
You could use tcpdump to see what's going on (does the server reply to SYN?).
Note that it might very well be either a firewall setting, or a DoS protection
(some sort of backoff when there are too many SYN within a short interval).
--
New submission from Charles-François Natali:
This patch updates the socketserver module to use selectors.
It's simpler, will use poll() when available, and also fixes a bug where the
timeout would not be recomputed upon EINTR.
Note that I removed an EINTR-handling test from test_sockets
Charles-François Natali added the comment:
By the way, could you test with the patch available in issue #21040 ?
It'll use poll() instead of select(): I don't think it'll fix your problem,
but it'll be a nice test anyway :-)
--
__
Changes by Charles-François Natali :
Added file: http://bugs.python.org/file34593/socketserver_use_selectors-1.diff
___
Python tracker
<http://bugs.python.org/issue21
Changes by Charles-François Natali :
--
resolution: -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/i
New submission from Charles-François Natali:
Many buildbots are failing with this error:
"""
==
ERROR: idlelib.idle_test.test_warning (unittest.loader.Modu
Charles-François Natali added the comment:
This patch can't be reviewed: please re-generate without --git.
--
nosy: +neologix
___
Python tracker
<http://bugs.python.org/is
Charles-François Natali added the comment:
Zero-filling mmap's backing file isn't really optimal: why not use truncate()
instead? This way, it'll avoid completely I/O on filesystems that support
sparse files, and should still work on FS that don't.
--
Charles-François Natali added the comment:
> If I remember correctly the problem is that some OS like linux (and
probably others) do not really allocate space until something is written.
If that's the case then the process may get killed later on when it writes
something in the array.
Y
Charles-François Natali added the comment:
> Also, the FreeBSD man page for mmap() has the following warning:
That's mostly important for real file-backed mapping.
In our case, we don't want a file-backed mmap: we expect the mapping to fit
entirely in memory, so the writeback/rea
Charles-François Natali added the comment:
Indeed, I think it would make sense to consider this for 3.4, and even 2.7
if we opt for a simple fix.
As for the best way to fix it in the meantime, I'm fine with a buffered
zero-filling (the mere fact that noone ever complained until now pro
Charles-Axel Dein added the comment:
Hey - is there anything else I need to do here?
--
___
Python tracker
<http://bugs.python.org/issue20351>
___
___
Python-bug
Charles-François Natali added the comment:
> In Python 3, arenas are allocated using mmap(), so wherever the arena ends up
> in the address space shouldn't matter, should it?
Indeed, although the effect on cache locality isn't clear.
Also, I don't think this solves th
1401 - 1500 of 2227 matches
Mail list logo