[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-25 Thread Charles-François Natali
Charles-François Natali 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.n

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-25 Thread Charles-François Natali
Changes by Charles-François Natali : -- nosy: +mark.dickinson ___ Python tracker <http://bugs.python.org/issue12181> ___ ___ Python-bugs-list mailing list Unsub

[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 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). os.w

[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 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 an EPERM err

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-26 Thread Charles-François Natali
Charles-François Natali 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 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 f

[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 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&q

[issue12190] intern filenames in bytecode

2011-05-26 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22136/unnamed ___ Python tracker <http://bugs.python.org/issue12190> ___ ___ Python-bug

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-27 Thread Charles-François Natali
Charles-François Natali 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=kevent&apropos=0&sektion=0&manpath=OpenBSD+

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-05-27 Thread Charles-François Natali
Charles-François Natali 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 tho

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
New submission from Charles-François Natali : pipe2() makes it possible to create a pipe O_CLOEXEC or O_NONBLOCK atomically, which can be quite useful, especially in multi-threaded code. It would be nice to expose it in the os module. Patch attached. -- components: Library (Lib) files

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
Charles-François Natali added the comment: > Do you want to call the function with two arguments or one tuple with 2 > items? You may test both :-) The former. Fixed. > Hum, I'm not sure that it's revelant to test the time I didn't like it either, I just reused wh

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22147/posix_pipe2.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Pytho

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
Changes by Charles-François Natali : Added file: http://bugs.python.org/file22152/posix_pipe2.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Pytho

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22152/posix_pipe2.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Pytho

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
Changes by Charles-François Natali : Added file: http://bugs.python.org/file22154/posix_pipe2.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Pytho

[issue12196] add pipe2() to the os module

2011-05-27 Thread Charles-François Natali
Charles-François Natali added the comment: > +# A constant likely larger than the underlying OS pipe buffer size. > +# Windows limit seems to be around 512B, and most Unix kernels have a 64K > pipe > +# buffer size: take 1MB to be sure. > +PIPE_MAX_SIZE = 1024 * 1024 > &g

[issue12196] add pipe2() to the os module

2011-05-28 Thread Charles-François Natali
Charles-François Natali added the comment: > Out of interest, is there any reason that the configure check for pipe2 is a > special case near the bottom of configure.in instead of with all the other > function checks in the AC_CHECK_FUNCS[] section in the middle? No clue. I&#x

[issue12196] add pipe2() to the os module

2011-05-28 Thread Charles-François Natali
Changes by Charles-François Natali : -- nosy: +gregory.p.smith ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Python-bugs-list mailing list Unsub

[issue12196] add pipe2() to the os module

2011-05-28 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22154/posix_pipe2.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___ Pytho

[issue12196] add pipe2() to the os module

2011-05-28 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22151/support_pipe_max.diff ___ Python tracker <http://bugs.python.org/issue12196> ___ ___

[issue12196] add pipe2() to the os module

2011-05-28 Thread Charles-François Natali
Charles-François Natali added the comment: > I just nuked the pure Python POSIX subprocess implementation Nice. I've updated both patches to address Victor's comments on test_io and test_subprocess usage of PIPE_MAX_SIZE, and Ross' comment on pipe2's configure tests. I left subprocess use _po

[issue12157] join method of multiprocessing Pool object hangs if iterable argument of pool.map is empty

2011-05-28 Thread Charles-François Natali
Charles-François Natali added the comment: When map is called, a MapResult object is created, which adds itself to the Pool's result cache. When the pool is shut down, the result handler thread waits until the cache drains (while cache and thread._state != TERMINATE). But since no resu

[issue12196] add pipe2() to the os module

2011-05-29 Thread Charles-François Natali
Charles-François Natali added the comment: The Gentoo buildbot on which O_CLOEXEC test failed also chokes on test_pipe2: [ 10/355] test_posix test test_posix failed -- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_posix.py&q

[issue12196] add pipe2() to the os module

2011-05-29 Thread Charles-François Natali
Charles-François Natali added the comment: The test now runs fine on the buildbots, closing. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12196] add pipe2() to the os module

2011-05-30 Thread Charles-François Natali
Charles-François Natali added the comment: > support.linux_version() may be changed for requires_linux_version(2, 6, 27), > > but linux_version() is always used in tests to check the Linux version. > requires_linux_version() would only raise a SkipTest if the OS is Linux and > if > the kernel i

[issue12021] mmap.read requires an argument

2011-05-30 Thread Charles-François Natali
Charles-François Natali added the comment: The patch looks good to me. In your test, you don't explicitely close the mmap object: it's not a problem with CPython since it will get unmmapped, and the file descriptor - if it's a file-backed mapping - will get closed, as soon as

[issue12021] mmap.read requires an argument

2011-05-31 Thread Charles-François Natali
Charles-François Natali added the comment: > I noticed that RawIOBase.read, TextIOBase.read, etc also accept None as the > argument, treating it as -1. Should this be implemented, too? > That's because of the _PyIO_ConvertSsize_t converter, which silently converts None to -1. Th

[issue12196] add pipe2() to the os module

2011-05-31 Thread Charles-François Natali
Charles-François Natali added the comment: > I like your patch, it removes many duplicate code :-) > > Some comments: Patch attached. > Doc/whatsnew/3.3.rst Patch attached. -- Added file: http://bugs.python.org/file22209/pipe2_whatsnew.diff Added file: http://bugs.python.org/file222

[issue6560] socket sendmsg(), recvmsg() methods

2011-05-31 Thread Charles-François Natali
Charles-François Natali added the comment: > What needs to happen to get recvmsg() supported in Python? Well, I guess that the only reason is that no committer is motivated enough to bring this into Python: it's a rather large patch, and honestly, I'm not sure that many people are

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

2011-05-31 Thread Charles-François Natali
Charles-François Natali added the comment: > The wakeup fd now contains the number of each signal, and so the behaviour has > to change. I applied your patch and I added a test. Interesting. I suspected this would have an impact on the test_signal failure on the FreeBSD 6.4 b

[issue12235] subprocess.check_output throws wrong exception if non executable

2011-06-01 Thread Charles-François Natali
Charles-François Natali added the comment: Python is not raising this error, your OS is. It doesn't find the interpreter, and if you look carefully, it's clear why: bash: ***/src/webapp/tools/grab.sh: /bin/sh^M: bad interpreter: No such file or directory See the ^M after /bin/sh?

[issue12235] subprocess loses stderr information when _execute_child fails

2011-06-01 Thread Charles-François Natali
Charles-François Natali added the comment: > I think it should at least include "bad interpreter", otherwise it is a tad > misleading. It just forwards the error raised by the exec system call: $ cat foo.sh #! /bin/foo $ strace ./foo.sh execve("./foo.sh",

[issue12196] add pipe2() to the os module

2011-06-01 Thread Charles-François Natali
Charles-François Natali added the comment: > requires_linux_version() should also be a decorator. Patch attached. -- Added file: http://bugs.python.org/file22219/support_linux_version.diff ___ Python tracker ___

[issue1495802] cygwin: popen3 lock up

2011-06-02 Thread Charles-François Natali
Charles-François Natali added the comment: It's not a bug. so.readlines reads the subprocess' stdout until EOF is encountered, but in the meantime, if it writes a lot to stderr, the corresponding pipe fills up, and the subprocess blocks on the write. You should use Popen's com

[issue5384] mmap and exception type

2011-06-02 Thread Charles-François Natali
Charles-François Natali added the comment: Here's a patch. -- keywords: +needs review, patch nosy: +charles-francois.natali, haypo stage: -> patch review versions: +Python 3.3 -Python 2.7, Python 3.1 Added file: http://bugs.python.org/file0/mmap_excepti

[issue12251] subprocess(..., stdout=sys.stderr) closes stderr for child

2011-06-03 Thread Charles-François Natali
Charles-François Natali added the comment: It's a duplicate of issue #10806, fixed in 2.7, 3.1 and 3.2. Closing. -- nosy: +charles-francois.natali resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Subprocess error if fds

[issue12224] problem with siginterrupt

2011-06-04 Thread Charles-François Natali
Charles-François Natali added the comment: Actually, it's part of a more general problem with EINTR being returned by many posix/socket module functions, see for example issue #7978. On the one hand, having to retry manually on EINTR is cumbersome, on the other hand, some code might re

[issue12021] mmap.read requires an argument

2011-06-06 Thread Charles-François Natali
Charles-François Natali added the comment: >> That's because of the _PyIO_ConvertSsize_t converter, which silently >> converts None to -1. >> There's probably a good reason for doing this in the _io module > > I'm not sure about the original reason, but

[issue12196] add pipe2() to the os module

2011-06-06 Thread Charles-François Natali
Charles-François Natali added the comment: Hmm, thinking about it, I don't see any reason to make the flags argument optional. Here's a patch changing that (also, pipe2 is now declared as METH_O instead of METH_VARARGS). -- Added file: http://bugs.python.org/file22265/pipe

[issue10115] Support accept4() for atomic setting of flags at socket creation

2011-06-06 Thread Charles-François Natali
Charles-François Natali added the comment: @nvetoshkin Could you update your patch against py3k? I've got a couple comments (can't login to Rietveld, it's probably due to the change of my tracker account name): if(flags & ~(SOCK_NONBLOCK | SOCK_CLOEXEC)) {

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

2011-06-07 Thread Charles-François Natali
Charles-François Natali added the comment: > Ok, the dependencies are now committed. Here is a new patch addressing > Charles-François' comments: select() is now called before each call to read() > when sentinels are given, to avoid race conditions. The patch looks fine to me

[issue12021] mmap.read requires an argument

2011-06-08 Thread Charles-François Natali
Charles-François Natali added the comment: Patch committed. Thanks for the report and the patch! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-08 Thread Charles-François Natali
New submission from Charles-François Natali : ossaudiodev's writeall method doesn't check that the FD is less than FD_SETSIZE when passing it to FD_SET: since FD_SET typically doesn't do bound check, it will write to a random location in memory (in this case on the stack). I

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-08 Thread Charles-François Natali
Changes by Charles-François Natali : Added file: http://bugs.python.org/file22285/test_oss.py ___ Python tracker <http://bugs.python.org/issue12287> ___ ___ Python-bug

[issue12187] subprocess.wait() with a timeout uses polling on POSIX

2011-06-08 Thread Charles-François Natali
Charles-François Natali added the comment: > For subprocess.wait(), we can do something with signals (SIGCHLD and/or > SIGCLD). There's just one problem: SIGCHLD is ignored by default, which means that sigwait and friends won't return when a child exits. Well, it actually

[issue12187] subprocess.wait() with a timeout uses polling on POSIX

2011-06-09 Thread Charles-François Natali
Charles-François Natali added the comment: > Antoine is right: we don't have to be portable. We don't have to, but writing one POSIX-conformant solution is better than writing N OS-specific solutions, no? That's what POSIX is about. > Should we block the signal? Yes.

[issue10897] UNIX mmap unnecessarily dup() file descriptor

2011-06-09 Thread Charles-François Natali
Charles-François Natali added the comment: Trying to revive this issue. I'm +1 on this change: duping the file descriptor is definitely unexpected and has some side effects. I think we should remove the call to dup and close, it's really the user's responsibility to avoid clo

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

2011-06-09 Thread Charles-François Natali
Charles-François Natali added the comment: I just noticed something "funny": signal_sigwait doesn't release the GIL, which means that it's pretty much useless :-) Patch attached. Also, test_sigwait doesn't block the signal before calling sigwait: it happens to work because there's only one thre

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-09 Thread Charles-François Natali
Charles-François Natali added the comment: > You don't check that 0 <= fd (e.g. oss.close()). > Actually, none of ossaudiodev's method does... This makes it even easier to trigger a segfault (at least on RHEL4): """ import ossaudiodev o = ossaudiodev.open('/dev/dsp', 'w') o.close() o.writeal

[issue8407] expose pthread_sigmask(), pthread_kill(), sigpending() and sigwait() in the signal module

2011-06-10 Thread Charles-François Natali
Charles-François Natali added the comment: >> I just noticed something "funny": signal_sigwait doesn't release >> the GIL, which means that it's pretty much useless :-) > > sigwait() is not useless: the signal is not necessary send by another thread. > The signal can be send by alarm(), from a

[issue9788] atexit and execution order

2011-06-10 Thread Charles-François Natali
Charles-François Natali added the comment: > I don't think the order should be defined. I disagree. The C standard explicitely states that the functions are called in LIFO order (which is the natural order in this case). The current implementation guarantees LIFO order, I think it s

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Charles-François Natali added the comment: Two patches attached: - a patch checking that the ossaudiodev object isn't closed - a patch adding _PyIsSelectable_fd() -- Added file: http://bugs.python.org/file22324/is_selectable.diff Added file: http://bugs.python.org/file22325/oss_check_c

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22284/oss_select.diff ___ Python tracker <http://bugs.python.org/issue12287> ___ ___ Pytho

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22301/oss_check_closed.diff ___ Python tracker <http://bugs.python.org/issue12287> ___ ___

[issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4 buildbot

2011-06-10 Thread Charles-François Natali
New submission from Charles-François Natali : http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 6.4 3.x/builds/1570/steps/test/logs/stdio """ [ 29/356] test_signal Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Charles-François Natali added the comment: > In oss_check_closed.diff, you might want to add tests for the other > methods as well. I've added checks for other methods (not all of them, there are quite a few). I've also added a check for the mixer object. > You may add par

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Changes by Charles-François Natali : Added file: http://bugs.python.org/file22327/oss_check_closed.diff ___ Python tracker <http://bugs.python.org/issue12287> ___ ___

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22324/is_selectable.diff ___ Python tracker <http://bugs.python.org/issue12287> ___ ___ Pytho

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-10 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22325/oss_check_closed.diff ___ Python tracker <http://bugs.python.org/issue12287> ___ ___

[issue12310] Segfault in test_multiprocessing

2011-06-11 Thread Charles-François Natali
Charles-François Natali added the comment: I think it might be related to Issue #6721. Using a mutex/condition variable after fork (from the child process) is unsafe: it can lead to deadlocks, and on OS-X, it seems like it can lead to segfaults. Normally, Queue's synchronization primi

[issue10115] Support accept4() for atomic setting of flags at socket creation

2011-06-11 Thread Charles-François Natali
Charles-François Natali added the comment: No one seems to object, and since this approach has been suggested by Martin and is consistent with the posix module's policy (i.e. a thin wrapper around the underlying syscall), I guess you can go

[issue12287] ossaudiodev: stack corruption with FD >= FD_SETSIZE

2011-06-11 Thread Charles-François Natali
Charles-François Natali added the comment: For oss_check_closed.diff, should I apply it to default only or to every branch? -- ___ Python tracker <http://bugs.python.org/issue12

[issue10897] UNIX mmap unnecessarily dup() file descriptor

2011-06-11 Thread Charles-François Natali
Charles-François Natali added the comment: > Perhaps by adding some new argument to the mmap constructor? (dup_fd = True) I don't really like the idea of exposing the FD duplication to the user, because: - it's an implementation detail - it doesn't reflect any argument

[issue12310] Segfault in test_multiprocessing

2011-06-11 Thread Charles-François Natali
Charles-François Natali added the comment: Yes, I also tried this. This fixed the test_multiprocessing failure, but I think it triggered a failure in test_concurrent_futures (didin't look in more detail). Would it be possible to try this on the buildbot to see if it fixes the segf

[issue8372] socket: Buffer overrun while reading unterminated AF_UNIX addresses

2011-06-12 Thread Charles-François Natali
Charles-François Natali added the comment: The patches look good to me, except that instead of passing (addrlen > buflen) ? buflen : addrlen as addrlen argument every time makesockaddr is called, I'd prefer if this min was done inside makesockaddr itself, i.e. perform min(addrlen

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-06-13 Thread Charles-François Natali
Charles-François Natali added the comment: > If there are only two versions of the structure on all operating > systems, we can add a check in configure Isn't it a bit overkill? OpenBSD is the only OS to define struct kevent that way, adding a #ifdef __OpenBSD__ check would

[issue12316] test_signal: test_sigwait_thread failure on FreeBSD 6.4 buildbot

2011-06-13 Thread Charles-François Natali
Charles-François Natali added the comment: Patch attached: - a new process is spawned (using assert_python_ok()) to avoid undefined behavior (and crash on FreeBSD) - I've kept SIGUSR1 default handler, because, as noted in http://bugs.python.org/issue8407#msg138066 , there can be subtle differen

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

2011-06-13 Thread Charles-François Natali
New submission from Charles-François Natali : Linus recently decided that the next Linux kernel version would 3.0 [1]. As a consequence, sys.platform (which is actually MACHDEP) will be 'linux3' on machines running Linux 3 kernels, and tests checking explicitely against 'linu

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

2011-06-13 Thread Charles-François Natali
Charles-François Natali added the comment: > I would expect changing sys.platform will also break a lot of third- > party code. Maybe, but this would be an application bug. Here's sys.platform current implementation: const char * Py_GetPlatform(void) { return PLATFORM; } And

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

2011-06-13 Thread Charles-François Natali
Changes by Charles-François Natali : -- nosy: +lemburg, loewis ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list mailing list Unsub

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

2011-06-14 Thread Charles-François Natali
Charles-François Natali added the comment: > I'm sure Linus Torvalds is fully aware of the possible > consequences of the version change, and just accepted the breakage > that this would cause. Any application relying on sys.platform == 'linux2' is already broken. It&

[issue12373] Duplicate packets in Multicast Receiver

2011-06-20 Thread Charles-François Natali
Charles-François Natali added the comment: This is normal. You're binding twice to the same port thanks to SO_REUSEADDR, but in case of multiple binds to the same UDP port, all packets received are duplicated by the kernel to every socket. Closing as invalid. -- nosy: +neo

[issue12373] Duplicate packets in Multicast Receiver

2011-06-20 Thread Charles-François Natali
Charles-François Natali added the comment: Note that the duplication is mandatory for multicast, but with unicast the kernel is free to do whatever he wants, most of the time only one socket will receive it. -- ___ Python tracker <h

[issue12326] Linux 3: tests should avoid using sys.platform == 'linux2'

2011-06-20 Thread Charles-François Natali
Charles-François Natali added the comment: > However, it appears to me that vast majority of them is broken anyway, > because what they really mean to check is That's exactly my point. Code checking sys.platform against 'linux2' is already broken, there's no poin

[issue12352] multiprocessing.Value() hangs

2011-06-20 Thread Charles-François Natali
Charles-François Natali added the comment: Thanks for reporting this. There's indeed a bug which can lead to this deadlock. Relevant code in Lib/multiprocessing/heap.py - the BufferWrapper class uses a single Heap() shared among instances, protected by a mutex (threading.Lock), from

[issue12363] test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

2011-06-20 Thread Charles-François Natali
Charles-François Natali added the comment: The patch looks good to me. In the subprocess, why not use the standard 0 exit code in case of success? Also, points 1 and 3 could be handled simply by having the parent process send a signal to the child (but this wouldn't address the timeout

[issue12352] multiprocessing.Value() hangs

2011-06-21 Thread Charles-François Natali
Charles-François Natali added the comment: > The obvious solution is to use a recursive lock instead. Note that it's not really a solution, just a workaround to avoid deadlocks, become this might lead to a corruption if free is called while the heap is in an inconsistent state. I have

[issue12352] multiprocessing.Value() hangs

2011-06-21 Thread Charles-François Natali
Charles-François Natali added the comment: > Looking closely to the gdb stack, there is that frame: Yeah, but it calls _free, which runs unlocked. That's not the problem. > I am still unable to reproduce the bug in a simple script. Try with this one: """ import

[issue12363] test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

2011-06-21 Thread Charles-François Natali
Charles-François Natali added the comment: The test still fails on FreeBSD 7.2, Tiger and Debian parallel: """ == FAIL: test_siginterrupt_on (test.test_signal.S

[issue12363] test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

2011-06-21 Thread Charles-François Natali
Charles-François Natali added the comment: Duh, don't know what I was thinking: the syscall is not restarted (even though ERESTARTSYS is displayed by strace): the real problem is that the 3s timeout to communicate is not enough, because spawning a new interpreter can take a long time (Antoine c

[issue12363] test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

2011-06-21 Thread Charles-François Natali
Changes by Charles-François Natali : Added file: http://bugs.python.org/file22421/test_siginterrupt.diff ___ Python tracker <http://bugs.python.org/issue12363> ___ ___

[issue12363] test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

2011-06-21 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22420/test_siginterrupt.diff ___ Python tracker <http://bugs.python.org/issue12363> ___ ___

[issue12363] test_signal.test_without_siginterrupt() sporadic failures on FreeBSD 6.4

2011-06-21 Thread Charles-François Natali
Changes by Charles-François Natali : -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue12363> ___ ___ Python-bugs-list mailing list Un

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-06-22 Thread Charles-François Natali
Charles-François Natali added the comment: Here's a patch. -- keywords: +needs review, patch stage: -> patch review Added file: http://bugs.python.org/file22423/kevent_openbsd.diff ___ Python tracker <http://bugs.python.org

[issue12181] SIGBUS error on OpenBSD (sparc64)

2011-06-22 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22423/kevent_openbsd.diff ___ Python tracker <http://bugs.python.org/issue12181> ___ ___

[issue12372] semaphore errors on AIX 7.1

2011-06-23 Thread Charles-François Natali
Charles-François Natali added the comment: Patch attached. I've used a wildcard so that it won't break when AIX 8 goes out (and it's POSIX). -- keywords: +needs review, patch nosy: +haypo, neologix stage: -> patch review Added file: http://bugs.py

[issue12372] semaphore errors on AIX 7.1

2011-06-24 Thread Charles-François Natali
Charles-François Natali added the comment: > Nobody is able to get more information, or maybe nobody wants to dig this > issue. It would be better to get the real cause of the issue, Well, it looks like a libc or kernel bug, and we probably can't do much about it. Just falling ba

[issue12392] pthread_kill() doesn't work on the main thread on FreeBSD6

2011-06-24 Thread Charles-François Natali
Charles-François Natali added the comment: > Attached patch implements the suggested fix. The patch looks good to me. > It would be possible to fix the test to fail instead of blocking I think this issue deserves a specific test, since: - test_pending tests something completely different - a

[issue5114] 2.7: test_threading hangs on Solaris

2011-06-25 Thread Charles-François Natali
Charles-François Natali added the comment: I'm closing. Feel free to re-open if this fails with 2.7 or 3.2. -- resolution: -> duplicate status: open -> closed superseder: -> Throw away more radioactive locks that could be held across a fork i

[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"

2011-06-25 Thread Charles-François Natali
Charles-François Natali added the comment: test_2_join_in_forked_process fails on FreeBSD 6.4 buildbot. http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 6.4 3.x/builds/1606/steps/test/logs/stdio """

[issue12410] Create a new helper function that enable to test that an operation don't hang more than a given timeout.

2011-06-25 Thread Charles-François Natali
Charles-François Natali added the comment: It's a little bit more complicated than that: - signals and threads don't mix well together - this will make syscalls fail with EINTR - the old SIGALRM handler is lost - etc In short, don't use signals. I'm not sure there'

[issue12352] multiprocessing.Value() hangs

2011-06-25 Thread Charles-François Natali
Charles-François Natali added the comment: Patch (with test) attached. It disables the garbage collector inside critical sections. Of course, if another thread re-enables the gc while the current thread is inside a critical section, things can break (the probability is really low, but who knows

[issue12352] multiprocessing.Value() hangs

2011-06-25 Thread Charles-François Natali
Changes by Charles-François Natali : -- keywords: +patch Added file: http://bugs.python.org/file22476/heap_gc_deadlock.diff ___ Python tracker <http://bugs.python.org/issue12

[issue12352] multiprocessing.Value() hangs

2011-06-25 Thread Charles-François Natali
Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22476/heap_gc_deadlock.diff ___ Python tracker <http://bugs.python.org/issue12352> ___ ___

[issue12352] multiprocessing.Value() hangs

2011-06-25 Thread Charles-François Natali
Changes by Charles-François Natali : Added file: http://bugs.python.org/file22477/heap_gc_deadlock.diff ___ Python tracker <http://bugs.python.org/issue12352> ___ ___

[issue12352] multiprocessing.Value() hangs

2011-06-25 Thread Charles-François Natali
Charles-François Natali added the comment: [...] > def free(self, block): >  if self._lock.acquire(False): >     self._exec_pending_free() >     self._free(block) >  else: >     # malloc holds the lock >     self._pending_free.append(block) > _pending_free uses a lo

[issue11870] test_3_join_in_forked_from_thread() of test_threading hangs 1 hour on "x86 Ubuntu Shared 3.x"

2011-06-25 Thread Charles-François Natali
Charles-François Natali added the comment: > This skip gives very few information, and it is duplicated for each > function. I would prefer a constant of the "broken OSes" with your > following comment attached to the constant: Ok, I'll try to write something alon

[issue12413] make faulthandler dump traceback of child processes

2011-06-25 Thread Charles-François Natali
New submission from Charles-François Natali : As noted in issue #11870, making faulthandler capable of dumping child processes' tracebacks could be a great aid in debugging tricky deadlocks involving for example multiprocessing and subprocess. Since there's no portable way to find

[issue12352] multiprocessing.Value() hangs

2011-06-26 Thread Charles-François Natali
Charles-François Natali added the comment: [...] > I don't like touching such global "variable", but you are right. > Well, I don't like it either, but I can't really think of any other solution. Antoine, any thought on that? -- ___

<    1   2   3   4   5   6   7   8   9   10   >