[issue11912] PaX triggers a segfault in dlopen

2011-05-01 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Is there any reason not to close this as a CPython issue? No, it's definitely not a CPython issue. I'm closing as invalid. -- resolution: - invalid status: open - closed title: Python shouldn't use the mprotect() system

[issue11849] glibc allocator doesn't release all free()ed memory

2011-05-02 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: I've had some time to look at this, and I've written a quick demo patch that should - hopefully - fix this, and reduce memory fragmentation. A little bit of background first: - a couple years ago (probably true when pymalloc was

[issue11849] glibc allocator doesn't release all free()ed memory

2011-05-02 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: I guess the final patch will have to guard the mallopt() call with some #ifdef? Yes. See attached patch pymalloc_frag.diff It's the first time I'm playing with autotools, so please review this part really carefully ;-) (also, I

[issue11849] glibc allocator doesn't release all free()ed memory

2011-05-02 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file21696/gc_trim.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11849

[issue11849] glibc allocator doesn't release all free()ed memory

2011-05-02 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file21858/pymem.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11849

[issue8498] Cannot use backlog = 0 for sockets

2011-05-03 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: To revive this issue, I tried to write a unit test to verify the behaviour. Onfurtunately, the test doesn't work and I don't understand why. I hope, someone here is more enlightend than me... The semantic of listen's backlog

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-03 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: # A lock taken from the current thread should stay taken in the # child process. Note that I'm not sure of how to implement this. After a fork, even releasing the lock can be unsafe, it must be re-initialized, see following

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-03 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Yes, we would need to keep track of the thread id and process id inside the lock. We also need a global variable of the main thread id after fork, and a per-lock taken flag. Synopsis:    def _reinit_if_needed(self

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Oops, for liunxthreads, you should of course read different PIDs, not same PID. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721

[issue3526] Customized malloc implementation on SunOS and AIX

2011-05-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Also that addresses the issue of two threads inside different malloc implementations at the same time: it is currently not allowed with PyMem_Malloc. That's not true. You can perfectly have one thread inside PyMem_Malloc while

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: - what's current_thread_id ? If it's thread_get_ident (pthread_self), since TID is not guaranteed to be inherited across fork, this won't work Ouch, then the approach I'm proposing is probably doomed. Well, it works on Linux

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-04 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Please disregard my comment on PyEval_ReInitThreads and _after_fork: it will of course still be necessary, because it does much more than just reinitializing locks (e.g. stop threads). Also, note that both approaches don't handle

[issue8498] Cannot use backlog = 0 for sockets

2011-05-05 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Thanks for the tip. I added the unit test and uploaded my final patch (which includes all changes). A couple comments (note that I'm not entitled to accept or commit a patch, so feel free to ignore them if I'm just being a pain

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

2011-05-05 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: You can not pickle individual objects larger than 2**31. Indeed, but that's not what's happening here, the failure occurs with much smaller objects (also, note the OP's cPickle is perfectly capable of pickling these objects

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

2011-05-06 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file21901/pending_signals-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8407

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

2011-05-06 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Oops. Victor, my mouse got stuck and I mistakenly removed your pending_signals-2 patch. I'm really sorry about this, could you re-post it? To try to make up for this, a small comment: In signal_sigwait, at the end of the function

[issue11877] Change os.fsync() to support physical backing store syncs

2011-05-07 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: I'll attach 11877.4.diff A couple comments: static PyObject * posix_fsync(PyObject *self, PyObject *args, PyObject *kwargs) { PyObject *retval = NULL; auto PyObject *fdobj; auto int full_fsync = 1; Why are you using

[issue12031] subprocess module does not accept file twice

2011-05-08 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: It's a duplicate of issue #11432: http://bugs.python.org/issue11432 -- nosy: +neologix resolution: - out of date status: open - closed superseder: - webbrowser.open on unix fails

[issue12015] possible characters in temporary file name is too few

2011-05-09 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Could someone explain me what's the risk on a case-insensitive filesystem? Since files are created with O_CREAT|O_EXCL, I don't see where the problem is. -- nosy: +neologix ___ Python

[issue12015] possible characters in temporary file name is too few

2011-05-09 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: @Nick I fully agree with you, but my point was that it doesn't make it less safe on case-insensitive filesystems. Apart from that, it's of course better to increase the length of the random sequence

[issue5114] 2.7: test_threading hangs on Solaris

2011-05-09 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Hmm. I think this was probably fixed by Gregory in issue #6643 (it's not in Python 2.7.1). Could you try with Python 3.2, or a current snapshot? -- nosy: +neologix ___ Python tracker rep

[issue8498] Cannot use backlog = 0 for sockets

2011-05-09 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: The patch looks fine to me: you just need to find someone interested in reviewing and committing it (didn't find anyone listed as expert for the socket module). -- ___ Python tracker rep

[issue11877] Change os.fsync() to support physical backing store syncs

2011-05-09 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Steffen, you changed the default to doing a full sync in your last patch: while I was favoring that initially, I now agree with Ronald and Antoine, and think that we shouldn't change the default behaviour. The reason being that Apple

[issue12044] subprocess.Popen.__exit__ doesn't wait for process end

2011-05-10 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: There's just one thing I'm concerned with. People using context managers tend to expect the __exit__ method to perform cleanup actions and release corresponding resources if necessary, for example closing the underlying file or socket

[issue12054] test_socket: replace custom _get_unused_port() by support.find_unused_port()

2011-05-10 Thread Charles-François Natali
New submission from Charles-François Natali neolo...@free.fr: Lib/test/test_socket.py uses custom _get_unused_port to return a port which will be likely available for binding in some tests. The same functionality is already provided by support.find_unuse_port, let's make use of it. Patch

[issue12044] subprocess.Popen.__exit__ doesn't wait for process end

2011-05-11 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: I'm re-opening this issue, since Gregory agrees to change the current behaviour. Patch attached (along with test and documentation update). -- components: +Library (Lib) keywords: +patch resolution: rejected - status: closed

[issue11877] Change os.fsync() to support physical backing store syncs

2011-05-12 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Calling fsync on a file descriptor referring to a tty doesn't make much sense. On Linux, this fails with EINVAL: $ python -c 'import os; os.fsync(1)' Traceback (most recent call last): File string, line 1, in module OSError: [Errno 22

[issue11877] Change os.fsync() to support physical backing store syncs

2011-05-12 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: and if they do they thus really strive for data integrity, so call fsync() as a fallback for the security which Apple provides. Why? If I ask a full sync and it fails, I'd rather have an error returned so that I can take

[issue12060] Python doesn't support real time signals

2011-05-12 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: If the C signal handler is called twice, the Python signal handler is only called once. It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-of-order

[issue12060] Python doesn't support real time signals

2011-05-12 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Evaluate Python code in a signal handler is really not a good idea! I know, you're limited to async-safe functions, among other things :-) because of the GIL, I don't think that we can do better. But with the GIL of Python 3.3,

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

2011-05-13 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Antoine, I've got a couple questions concerning your patch: - IIUC, the principle is to create a pipe for each worker process, so that when the child exits the read-end - sentinel - becomes readable (EOF) from the parent, so you know

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-13 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Hi, Hello Nir, Option (2) makes sense but is probably not always applicable. Option (1) depends on being able to acquire locks in locking order, but how can we determine correct locking order across libraries? There are indeed

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

2011-05-13 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Not exactly. The select is done on the queue's pipe and on the workers' fds *at the same time*. Thus there's no race condition. You're right, I missed this part, it's perfectly safe. But I think there's a problem with the new

[issue8604] Adding an atomic FS write API

2011-05-13 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Something's missing in all the implementations presented: to make sure that the new version of the file is available afer a crash, fsync must be called on the containing directory after the rename. -- nosy: +neologix

[issue12040] Expose a Process.sentinel property (and fix polling loop in Process.join())

2011-05-13 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Just a detail, but with the last version, select is retried with the full timeout (note that the signal you're the most likely to receive is SIGCHLD and since it's ignored by default it won't cause EINTR, so this shouldn't happen too

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

2011-05-13 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Interesting. There's something weird with the first child: === Child #1 = Thread 0x0445: Thread 0x0444: File /home/haypo/cpython/Lib/threading.py, line 237 in wait waiter.acquire() File /home/haypo/cpython/Lib

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

2011-05-14 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: This makes sense. I was suspecting a system limit exhaustion, maybe OOM or maximum number of threads, something like that. But at least on Linux, in OOM condition, the process would either get nuked by the OOM-killer

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-14 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Hello Steffen, First, thanks for testing this on OS-X: I only have access to Linux systems (I tested both the semaphore and the emulated semaphore paths). If I understand correctly, the patch works fine with the default build option

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

2011-05-14 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Indeed, it isn't, Pipe objects are not meant to be safe against multiple access. Queue objects (in multiprocessing/queues.py) use locks so they are safe. But if the write to the Pipe is not atomic, then the select isn't safe. select

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-14 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: a) We know the correct locking order in Python's std libraries so the problem there is kind of solved. I think that you're greatly under-estimating the complexity of lock ordering. If we were just implementing a malloc

[issue12060] Python doesn't support real time signals

2011-05-14 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: if you used the pipe approach you'd need to deal with the case of the write blocking (or failing if nonblocking) when the pipe buffer is full. Well, a pipe is 64K on Linux (4K on older kernels). Given that each signal received

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-15 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file21991/reinit_locks.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721

[issue6721] Locks in python standard library should be sanitized on fork

2011-05-15 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Is it possible the following issue is related to this one? It's hard to tell, the original report is rather vague. But the comment about the usage of the maxtasksperchild argument reminds me of issue #10332 Multiprocessing

[issue11877] Change os.fsync() to support physical backing store syncs

2011-05-15 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: (I'm not sure Rietveld sent the message so I post it here, sorry in case of duplicate). Steffen, I've made a quick review of your patch, in case you're interested. I think that this functionality can be really useful to some people

[issue12091] multiprocessing: simplify ApplyResult and MapResult with threading.Event

2011-05-16 Thread Charles-François Natali
New submission from Charles-François Natali neolo...@free.fr: Multiprocessing's MapResult and ApplyResult use a notification mechanism to signal callers when the underlying value is available. Instead of re-inventing the wheel, we could use threading.Event instead: this leads to cleaner

[issue10239] multiprocessing signal defect

2011-05-16 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Closing as duplicate of issue #9205. -- nosy: +neologix resolution: - duplicate status: open - closed superseder: - Parent process hanging in multiprocessing if children terminate unexpectedly

[issue12096] test_threading.test_waitfor() timeout (1 hour) on x86 Gentoo 3.x buildbot

2011-05-17 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: The sleep is too short: def f(): with cond: result = cond.wait_for(lambda : state==4) for i in range(5): time.sleep(0.01) with cond: state += 1

[issue6059] ctypes/uuid-related segmentation fault

2011-05-17 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: It's probably a libc buc, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453 Basically, when libraries are dynamically loaded in an interleaved way, this can lead to TLS being returned uninitialized, hence leading

[issue12096] test_threading.test_waitfor() timeout (1 hour) on x86 Gentoo 3.x buildbot

2011-05-17 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Here's a one-liner patch using the later approach (that way we're sure the test won't hang). -- keywords: +patch Added file: http://bugs.python.org/file22015/wait_for_race.diff ___ Python

[issue12098] Child process running as debug

2011-05-17 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Under Linux, child processes are created with fork(), so they're run with the exact same environment as the parent process (among which sys.flags.optimize). I don't know Windows at all, but since I've heard it doesn't have fork(), my

[issue6059] ctypes/uuid-related segmentation fault

2011-05-18 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Importing uuid before importing the other modules does not result in Seg Fault Alright. In that case, I'm closing this bug as invalid. Until distributions start shipping their glibc with this patch, the workaround is simply

[issue1746656] IPv6 Interface naming/indexing functions

2011-05-18 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Here's a patch: - those functions now accept and return str, not bytes arrays - some of them were not declared static, it's now fixed - use PyErr_SetFromErrno when errno is set - add tests (return type, nonexistent interface name/index

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-18 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: In python3, one can still use fcntl(f.fileno(), FD_SET, FD_CLOEXEC) Note that it's not atomic. -- nosy: +neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-19 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Here's a patch adding O_CLOEXEC to the os module, with test. This patch makes it possible to open and set a FD CLOEXEC atomically. O_CLOEXEC is part of POSIX.1-2008, supported by the Linux kernel since 2.6.23 and has been committed

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-19 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Using spawn_python() to check that os.O_CLOEXEC flag is correctly set seems overkill. Why not just testing fcntl.fcntl(f.fileno(), fcntl.F_GETFL) FD_CLOEXEC)? Because I couldn't find a place where the CLOEXEC flag was fully tested

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

2011-05-19 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Hello Christophe, First and foremost, I think that the FD_CLOEXEC approach is terminally broken, as it should have been the default in Unix. Now, we're stuck with this bad design. But we can't simply change the default to FD_CLOEXEC

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-20 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: To exclude races (in concurrent threads), this two ops should be done under lock (GIL?) That won't work, because open(), like other slow syscalls, is called without the GIL held. Furthermore, it wouldn't be atomic anyway (imagine

[issue1746656] IPv6 Interface naming/indexing functions

2011-05-20 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file22025/socket_if.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1746656

[issue1746656] IPv6 Interface naming/indexing functions

2011-05-20 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: You use UTF-8 encoding: Here's an updated patch taking your comments into account (I'm really blissfully ignorant when it comes to encoding issues, so I hope it will be OK this time). -- Added file: http://bugs.python.org

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

2011-05-20 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: That's not the intention (that's a gordian knot I *will* be keeping a safe distance from). The intention is to create a saner default situation for most python programs. I understand what you're saying, and I agree with you

[issue1746656] IPv6 Interface naming/indexing functions

2011-05-20 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: @neologix: You can commit it into Python 3.3. Tell me if you need help ;-) My first commit :-) What's the next step? Can this issue be closed, or should I wait until the tests pass on some buildbot

[issue1746656] IPv6 Interface naming/indexing functions

2011-05-20 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1746656 ___ ___ Python

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

2011-05-20 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file16758/urllib_redirect.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8035

[issue8035] urllib.request.urlretrieve hangs waiting for connection close after a redirect

2011-05-20 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Those URLs don't trigger the problem anymore, but AFAICT from the code, this problem is still present in py3k. Here's an updated patch. -- Added file: http://bugs.python.org/file22040/urllib_redirect.diff

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-21 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: It's actually an obvious case of heap fragmentation due to long-lived chunks being realloc()ed to a smaller size. Some malloc implementations can choke on this (e.g. OS-X's malloc is known to not shrink blocks when realloc() is called

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-21 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file16747/imaplib_read.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1441530

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

2011-05-21 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Thanks for reporting this, the current behaviour is clearly wrong. The child process doesn't need to - and shouldn't - inherit the server socket. The custom idiom when writting such code is to close the new socket (well, in TCP

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

2011-05-21 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: $ cat test_sock.py import socket import fcntl with socket.socket(socket.AF_INET, socket.SOCK_STREAM|socket.SOCK_CLOEXEC) as s: print(bool(fcntl.fcntl(s, fcntl.F_GETFD) fcntl.FD_CLOEXEC)) $ ./python test_sock.py True

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-21 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Patch looks ok. Is 3.x also affected? The I/O stack changed quite a bit in 3.x. I think it's not affected, but I can't reproduce this behaviour with glibc/eglibc, so don't just take my word for it. The reason is that in py3k,

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-21 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: In the buffered reader case, the result buffer is actually pre-allocated with the total size, making fragmentation even less likely. -- ___ Python tracker rep...@bugs.python.org http

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-22 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Digging a little deeper, here's the conclusion: - with py3k, fragmentation is less likely: the buffered reader returned by makefile() ensures that we can allocate only one result buffer for the total number of bytes read() (thanks

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-22 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Added file: http://bugs.python.org/file22063/imaplib_recv_27.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1441530

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-22 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file22044/imaplib_read.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1441530

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-22 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file22051/imaplib_ssl_makefile.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1441530

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-22 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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/rejected

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-22 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-23 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

2011-05-23 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-23 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue12158] platform: add linux_version()

2011-05-23 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

2011-05-23 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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 policy

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-23 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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 rep

[issue12105] open() does not able to set flags, such as O_CLOEXEC

2011-05-24 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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 rep...@bugs.python.org http

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

2011-05-24 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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 received while

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

2011-05-24 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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, since a new one

[issue5715] listen socket close in SocketServer.ForkingMixIn.process_request()

2011-05-24 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file22045/ss_fork_close.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5715

[issue1441530] socket read() can cause MemoryError in Windows

2011-05-24 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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: open

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

2011-05-25 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue12071] test_concurrent_futures.test_context_manager_shutdown() hangs on OpenIndiana

2011-05-25 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Since it's a OOM issue, can we close? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12071

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

2011-05-25 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr 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

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-25 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: It's an unaligned access: addr=0x21007b72c case T_LONGLONG: v = PyLong_FromLongLong(*(PY_LONG_LONG *)addr); sizeof(PY_LONG_LONG) == 8, but addr % 8 = 0x21007b72c % 8 == 4 -- nosy: +charles-francois.natali

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-25 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12181 ___ ___ Python

[issue12184] socketserver.ForkingMixin collect_children routine needs to collect only it's children

2011-05-26 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: In the common case, I don't think that the os.waitpid(0, 0) is the hot spot, but rather this: for child in self.active_children: os.waitpid(child, os.WNOHANG) It's called every time, and it's O(number of active children

[issue12184] socketserver.ForkingMixin collect_children routine needs to collect only it's children

2011-05-26 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Some precisions: 1) Of course, if a handler changes its process group through setsid/setpgrp, it won't be waited on. 2) If a handler running on behalf of a process which is the current process group leader calls setsid, it will get

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-26 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: OpenBSD's struct kevent definition looks fishy: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/event.h?rev=1.15;content-type=text%2Fplain struct kevent { u_int ident; /* identifier for this event

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-26 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: ident and data are not pointers, That's not the point. struct kevent declaration should be the following: struct kevent { uintptr_t ident;/* identifier for this event */ short filter; /* filter

[issue12191] Shutil - add chown() in order to allow to use user and group name (and not only uid/gid)

2011-05-26 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: I didn't test, but after skimming through the code I think that if an invalid user name/group name is provided, os.chown is passed None, which will fail with ValueError. It would be better to raise an explicit error like no such user

[issue12190] intern filenames in bytecode

2011-05-26 Thread Charles-François Natali
Changes by Charles-François Natali neolo...@free.fr: Removed file: http://bugs.python.org/file22136/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12190

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-27 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Hello Nicholas, kqueue is not standardized. You're probably right, but depending on the version of your manpages, the definition changes: http://www.openbsd.org/cgi-bin/man.cgi?query=keventapropos=0sektion=0manpath=OpenBSD+3.8arch

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-27 Thread Charles-François Natali
Charles-François Natali neolo...@free.fr added the comment: Concerning the differences between platforms, as noted, FreeBSD, NetBSD and OS-X are all consistent and I don't think it'll change tomorrow, so for now it's not a problem. Arbitrarily changing such structures definition - event

  1   2   3   4   5   6   7   8   9   10   >