[issue9955] multiprocessing.Pipe segmentation fault when recv of unpicklable object

Changes by Charles-François Natali : -- resolution: -> out of date stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.o

[issue12352] multiprocessing.Value() hangs

Charles-François Natali added the comment: > You are probably right. Can't we use a lock-less list? list.append is > atomic thanks to the GIL, isn't it? But I don't know how to implement > the lock-less list consumer. It would be nice to have a function to > remove an

[issue12413] make faulthandler dump traceback of child processes

Charles-François Natali added the comment: > You mean that the tracebacks of children should be dumped on a timeout of the > parent? Or do you also want them on a segfault of the parent? In my > experience, the most common problem with the multiprocessing and subprocess > modules

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

Charles-François Natali added the comment: > So people who say sys.platform shouldn't be used: what do you propose > to do with Lib/plat-linux2 (or, more generally, Lib/plat-*)? I can't speak, as I've never used those. But can't those directories be renamed

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

Charles-François Natali added the comment: Patch attached. -- Added file: http://bugs.python.org/file22489/test_threading_fork.diff ___ Python tracker ___diff -r fca745bc70be L

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

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22468/test_threading_fork.diff ___ Python tracker <http://bugs.python.org/issue11

[issue12352] multiprocessing.Value() hangs

Charles-François Natali added the comment: Here's a patch based on the second approach. -- Added file: http://bugs.python.org/file22490/heap_gc_deadlock_lockless.diff ___ Python tracker __

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

Charles-François Natali added the comment: > That would be incorrect for some systems. For example, FreeBSD does > change sets of symbolic constants across system releases (mostly > additions, but sometimes also removals). Back then, SunOS 4 and SunOS > 5 were completely unrel

[issue12352] multiprocessing.Value() hangs

Charles-François Natali added the comment: > Nice work! I also think heap_gc_deadlock_lockless.diff is good, except for > Victor's reservation: is it deliberate that you reversed the following two > statements in _free_pending_blocks(), compared to the code in free()? > &g

[issue12303] expose sigwaitinfo() and sigtimedwait() in the signal module

Charles-François Natali added the comment: > Oh, the problem is that sigwait() behaviour changes after a fork: it is > interrupted if an unexpected signal is received, but the signal handler is > not called. It behaves correctly (the signal handler is called) without the > fork

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

Charles-François Natali added the comment: > The way I see it is that Charles-François' patch trades a possibility of a > deadlock for a possibility of a child process running with inconsistent > states due to forcibly reinitialized locks. > Yeah, that's why I let thi

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

Charles-François Natali added the comment: > Well, I ping my view that we should: > Could you please detail the following points: - what would be the API of this atfork() mechanism (with an example of how it would be used in the library)? - how do you find the correct order to acquire lo

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

Charles-François Natali added the comment: > The initial problem was test_3_join_in_forked_from_thread() and the hangs > does still happen: > Yes, the patch was there to fix test_2_join_in_forked_from_thread. > [324/356] test_threading > Timeout (1:00:00)! > Thread 0x40424

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

Charles-François Natali added the comment: >> - how do you find the correct order to acquire locks in the parent process? > > One option is to use the import graph to determine call order of atfork > handlers. > If a current std library does not fit into this scheme we c

[issue12468] longjmp causes uninitialized stack frame

Charles-François Natali added the comment: longjmp() is used in only two places: ./Modules/fpectlmodule.c:longjmp(PyFPE_jbuf, 1); ./Modules/readline.c:longjmp(jbuf, 1); Both use it to jump out of a signal handler, which can lead to undefined behaviour (see https

[issue12472] Build failure on IRIX

Charles-François Natali added the comment: That's because struct timeval is not defined by on IRIX, or it doesn't get included in Modules/signalmodule.c. Can you try to compile the following code with the same compiler/options? """ #include int main(int argc, c

[issue12472] Build failure on IRIX

Charles-François Natali added the comment: Ok, what happens if you change, in Modules/signalmodule.c 20 #ifdef HAVE_SYS_TIME_H 21 #include 22 #endif to 21 #include and rebuild Python? -- ___ Python tracker <http://bugs.python.

[issue12469] test_faulthandler failures on FreeBSD 6

Charles-François Natali added the comment: What happens if you create the thread after having registered the SIGBUS handler? -- ___ Python tracker <http://bugs.python.org/issue12

[issue12472] Build failure on IRIX

Charles-François Natali added the comment: You can't include both and on IRIX... Nice one! A couple suggestions (in this order): 1) try putting "#include " before "#include "Python.h"" 2) try this: 20 #undef select 21 #include 3) fix the header yourse

[issue12469] test_faulthandler failures on FreeBSD 6

Charles-François Natali added the comment: >> On FreeBSD 6, os.kill(os.getpid(), signum) calls immediatly >> the signal handler before the creation of the first thread (...), >> whereas the signal handler is called "later" (when exactly?) after >> the creation

[issue12352] multiprocessing.Value() hangs

Charles-François Natali added the comment: Updated patch. -- Added file: http://bugs.python.org/file22545/heap_gc_deadlock_lockless.diff ___ Python tracker ___diff -r fcf242243

[issue12352] multiprocessing.Value() hangs

Changes by Charles-François Natali : Added file: http://bugs.python.org/file22546/heap_gc_deadlock_lockless.diff ___ Python tracker <http://bugs.python.org/issue12

[issue12352] multiprocessing.Value() hangs

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

[issue12352] multiprocessing.Value() hangs

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22490/heap_gc_deadlock_lockless.diff ___ Python tracker <http://bugs.python.org/issue12

[issue12352] multiprocessing.Value() hangs

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22545/heap_gc_deadlock_lockless.diff ___ Python tracker <http://bugs.python.org/issue12

[issue12468] longjmp causes uninitialized stack frame

Charles-François Natali added the comment: Digging a little deeper: - in ./Modules/fpectlmodule.c, the longjmp() is actually not used at all (dead code) - in Modules/readline.c, the jmp_buf is correctly initialized (well, there's a tiny race condition because SIGINT handler is inst

[issue12468] longjmp causes uninitialized stack frame

Charles-François Natali added the comment: And the backtrace leaves no doubt: === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f2415de61d7] /lib/x86_64-linux-gnu/libc.so.6(+0xfe169)[0x7f2415de6169] /lib/x86_64-linux-gnu/libc.so.6(__longjmp_chk+0x33

[issue12469] test_faulthandler failures on FreeBSD 6

Charles-François Natali added the comment: > Revert the patch doesn't change anything for the test suite. I know, but at least it doesn't change the default - be it broken - behaviour on FreeBSD 6. > I just fear that it is a little bit overkill just to support an "old&

[issue12352] multiprocessing.Value() hangs

Charles-François Natali added the comment: The test passes on all the buildbots, closing. greg, thanks for reporting this! -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bug

[issue7123] Multiprocess Process does not always exit when run from a thread.

Charles-François Natali added the comment: > I am pretty sure this is another instance of issue 6721. Indeed. Closing as duplicate. -- status: open -> closed superseder: -> Locks in python standard library should be sanitized on fork _

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

Changes by Charles-François Natali : -- keywords: +needs review stage: needs patch -> patch review ___ Python tracker <http://bugs.python.org/issue8035> ___ _

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

Charles-François Natali added the comment: That's because the other end of the pipe (p1) is open in the child process (FDs are inherited on fork()). Just add p1.close() at the beginning of fn() and you'll get EOF. Closing as invalid. -- nosy: +neologix resolution: ->

[issue10141] SocketCan support

Charles-François Natali added the comment: The patch looks good to me. A couple remarks: - could you please post it as a Mercurial diff? (it makes it easier to review and apply) @@ -1151,6 +1151,25 @@ makesockaddr(int sockfd, struct sockaddr } + return Py_BuildValue(&qu

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

Charles-François Natali added the comment: Well, in this regard it behaves like a Unix pipe/socket (in the duplex case it's implemented with a Unix domain socket), so I find it quite natural (of course, you have to know about FD inheritance upon fork()). I'm not convinced it&#

[issue12413] make faulthandler dump traceback of child processes

Charles-François Natali added the comment: > subprocess doesn't use a shell by default, and I don't think that > multiprocessing uses a shell to start Python. > No, but we precisely want subprocess/multiprocessing-created processes to be in the same process group.

[issue12488] multiprocessing.Connection does not communicate pipe closure between parent and child

Charles-François Natali added the comment: Alright. Luke, if you're motivated, feel free to provide a patch. The relevant file is Doc/library/multiprocessing.rst. -- ___ Python tracker <http://bugs.python.org/is

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

Charles-François Natali added the comment: [...] > A caveat is that since Python is an object oriented language it is more > common than with C that code from a higher level module will be invoked by > code from a lower level module, for example by calling an object method that &

[issue12469] test_faulthandler failures on FreeBSD 6

Charles-François Natali added the comment: > When signals are unblocked, pending signal ared delivered in the reverse order > of their number (also on Linux, not only on FreeBSD 6). I don't like this. POSIX doesn't make any guarantee about signal delivery order, except for r

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

Charles-François Natali added the comment: > Except for multiprocessing, does anyone know of any other module in the > standard library that uses fork() and threads at the > same time? After some grepping through the source I couldn't find any other > cases. The same probl

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

Charles-François Natali added the comment: >> We can't do that, it would break existing code. > > I would argue that such code is already broken. > - that's not necessarily true, if your code is carefully designed - we can't forbid fork() in a multi-threaded app

[issue12502] 100% cpu usage when using asyncore with UNIX socket

Charles-François Natali added the comment: It's looping in Lib/asyncore.py:poll select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 94}) select(4, [3], [3], [3], {30, 0}) = 1 (out [3], left {29, 94}) select(4, [3], [3], [3], {30, 0}) = 1 (out [3], lef

[issue12493] subprocess: Popen.communicate() doesn't handle EINTR in some cases

Charles-François Natali added the comment: Out of curiosity, how could SIGALRM be missing on a Unix system? Maybe you mean something like @unittest.skipUnless(hasattr(errno, EINTR), "Requires errno.EINTR") -- nosy:

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > @neologix: New try. Why did you remove your patch? > Sorry, I completely forgot about this issue. Because it was incorrect (it would have fixed the SIGBUS, but would have produced incorrect results). IIRC, the problem is that those members ar

[issue12502] 100% cpu usage when using asyncore with UNIX socket

Charles-François Natali added the comment: > Looks good, the patch seems to fix the problem. Alright. Giampaolo, do you agree? Also, I noticed that test_asyncore currently only tests AF_INET sockets. I'm working a patch to add AF_UNIX (and maybe AF_INET

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

Charles-François Natali added the comment: > @neologix: I don't understand why do you want to hurry, this issue will not > be fixed in the next release (3.2.1, it's too late), and I don't think that > the next release (3.3? or is it something before?) will come befor

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

Charles-François Natali added the comment: Are you using a 2.6.38 kernel? There was a regression in early 2.6.38 kernels that caused FUTEX_WAIT with a timeout to never return after a suspend-resume, see: https://lkml.org/lkml/2011/4/13/23 It's been fixed by this commit: http://git.kerne

[issue12539] multiprocessing.Event.wait(n) doesn't time out properly

Charles-François Natali added the comment: >> Are you using a 2.6.38 kernel? > Yes Alright, closing as invalid then. -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker <h

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: > In the posix_lseek function check for result != -1 instead of checking > for result < 0 in return code checks of the value returned by lseek. +1 This can be useful when parsing /dev/mem on x86_64, for example. > In addition I wo

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

Charles-François Natali added the comment: Brian, any comment about the Windows part (see Victor's message, http://bugs.python.org/issue12287#msg138137) ? -- nosy: +brian.curtin ___ Python tracker <http://bugs.python.org/is

[issue12502] 100% cpu usage when using asyncore with UNIX socket

Charles-François Natali added the comment: Patch committed, closing. Alexey, thanks for reporting this. (I'll open a separate issue to increase the tests coverage). -- resolution: -> fixed stage: -> committed/rejected status: ope

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

Charles-François Natali added the comment: Here we go, first Linux3-related bug report: https://bugs.gentoo.org/show_bug.cgi?id=374579 (see issue #12571). -- ___ Python tracker <http://bugs.python.org/issue12

[issue12556] Disable size checks in mmap.mmap()

Charles-François Natali added the comment: A couple remarks: - if st_size == 0, then you have to specify an explicit length (your example passes 0, which would fail with EINVAL without the check) - most enties in /proc don't support mmap file operation, so it's likely to fail an

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: > So even on solaris the behavior seems to be filesystem dependent. > So I'd suggest forgetting about this part. Would you like to write a patch for the first point? -- ___ Python tra

[issue12372] semaphore errors on AIX 7.1

Charles-François Natali added the comment: So, what do we do now? -- ___ Python tracker <http://bugs.python.org/issue12372> ___ ___ Python-bugs-list mailin

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

Charles-François Natali added the comment: Trying to revive this issue, here's a comment I left on Rietveld: """ > I don't agree, the documentation states that full_sync will cause a flush to > stable storage where supported and a plain fsync where it isn'

[issue12372] semaphore errors on AIX 7.1

Changes by Charles-François Natali : -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue12372> ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Charles-François Natali added the comment: > I'm still in favor of keeping sys.platform == 'linux3', and you? > So do I. > For plat-linux3, should we regenerate this directory (I cannot do that, I > don't have Linux 3.0 yet) or can we just use a symbolic link?

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: > Hi.  I can submit a patch for the first part.  Should I submit on this issue > tracker item? > Sure. -- ___ Python tracker <http://bugs.python.or

[issue12372] semaphore errors on AIX 7.1

Charles-François Natali added the comment: Patch committed: this should fix POSIX semaphores failures on AIX. Reshmi, thanks for reporting this! -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _

[issue12556] Disable size checks in mmap.mmap()

Charles-François Natali added the comment: > By the way, I've checked mmap(2) manpage -- it looks like the C-version has > nothing > against mmaping 0-sized files, Why does Python's `mmap` still checks file > size? It doesn't check explicitely that the size is non-0,

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

Charles-François Natali added the comment: > Still -1. It should be renamed to 'linux' in future releases, and > back-patched to 'linux2' for maintenance releases. > I really don't see any advantage to this solution: - sys.platform currently has a clear and

[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Charles-François Natali added the comment: Patch attached. > For lseek, we can rely on errno. Try something like that: > > errno = 0; > offset = lseek(...); > if (offset == (off_t)-1 && errno) /* error */ > It's a little bit overkill :-) (for mktime, time_t can overflow easily on 32-bit). >

[issue12592] modify configure.in to detect OpenBSD 5.x

Charles-François Natali added the comment: Patch attached (this one should also work with future major releases). -- keywords: +needs review, patch nosy: +neologix, pitrou stage: -> patch review Added file: http://bugs.python.org/file22720/configure_openbsd.d

[issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)

Charles-François Natali added the comment: > Previous frame inner to this frame (corrupt stack?) Interesting. Could you post the result of: $ valgrind --tool=memcheck --suppressions=Misc/valgrind-python.supp Modules/_testembed after having un-commented the ADDRESS_IN_RANGE suppressi

[issue12592] modify configure.in to detect OpenBSD 5.x

Charles-François Natali added the comment: Patch committed. Rémi, thanks for reporting this (and other OpenBSD-specific bugs :-). -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python track

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

Charles-François Natali added the comment: > One could argue that something had happened before the fsync(2), > so that code which blindly did so is too dumb to do any right > decision anyway. Even PEP 3151 won't help. I don't understand. If the syscall supposed

[issue8714] Delayed signals in the REPL on OpenBSD (possibly libpthread related)

Charles-François Natali added the comment: > This behavior was introduced (exposed by?) r68460. After a quick look, I don't see anything wrong with r68460, but it might very well have exposed this problem which was lurking before. > When Python is compiled without threads, the

[issue12620] pending calls: make `pendingbusy` flag static to Py_MakePendingCalls()

New submission from Charles-François Natali : Trivial patch. In Python/ceval.c, when compiled with threads, make the `pendingbusy` flag used to guard against reentrant calls static to Py_MakePendingCalls(). Also, make it an int and rename it to `busy` to be consistent with the non-threaded

[issue12588] test_capi.test_subinterps() failed on OpenBSD (powerpc)

Charles-François Natali added the comment: and Darwin). It would have been useful... """ interp 0x0, thread state 0x81855380: Program received signal SIGSEGV, Segmentation fault. """ Here, the interpreter state is NULL, and this shouldn't happen. It co

[issue12620] pending calls: make `pendingbusy` flag static to Py_MakePendingCalls()

Changes by Charles-François Natali : -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

Charles-François Natali added the comment: Demo: """ cf@neobox:~/cpython$ ./python -c "import pydoc; print(pydoc.synopsis('Lib/os.py'))" OS routines for Mac, NT, or Posix depending on what system we're on. [51835 refs] cf@neobox:~/cpython$ touch -t 197

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: Looks similar to issue #8263, which is in turn similar to #12469 (see http://bugs.python.org/issue12469#msg139620 and http://bugs.python.org/issue12469#msg139626 for original explanations): normally, pending signals are checked when the process returns

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

Charles-François Natali added the comment: Well, the function is part of pydoc's public API, but the inner working of the cache mechanism is completely private: this won't have any impact, other than fixing the bug :-) -- ___ Python trac

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: > So I'd say the easier solution is to skip this test on OpenSolaris, > like it's done on FreeBSD6 since issue #8263. Another option could be to add a dummy syscall, like os.getpid(), before checking that the handler got called - this

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: > No, it's a feature of the new GIL. When I look at 2.7's code, I see something different - _Py_Ticker is reset in Py_AddPendingCall(): int Py_AddPendingCall(int (*func)(void *), void *arg) { [...] /* signal main loop */ _Py_Ticker = 0; p

[issue12560] libpython.so not built on OpenBSD

Charles-François Natali added the comment: The patch looks good to me. As for the other failures, it would probably be interesting to open a separate issue, no? -- ___ Python tracker <http://bugs.python.org/issue12

[issue12560] libpython.so not built on OpenBSD

Charles-François Natali added the comment: Patch committed. Stefan, thanks for the report and the patch! -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bug

[issue12498] asyncore.dispatcher_with_send, disconnection problem + miss-conception

Charles-François Natali added the comment: Hello, > Actually the class asyncore.dispatcher_with_send do not handle properly > disconnection. When the endpoint shutdown his sending part of the socket, > but keep the socket open in reading, the current implementation of > dispatch

[issue12498] asyncore.dispatcher_with_send, disconnection problem + miss-conception

Changes by Charles-François Natali : -- components: +Library (Lib) -IO stage: -> needs patch type: -> behavior versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/i

[issue10141] SocketCan support

Charles-François Natali added the comment: Thanks for updating your patch. I've done a review, available here: http://bugs.python.org/review/10141/show -- ___ Python tracker <http://bugs.python.org/is

[issue11784] multiprocessing.Process.join: timeout argument doesn't specify time unit.

Charles-François Natali added the comment: Committed to default. Patrick, thanks for the patch! -- nosy: +neologix resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7 ___ Pytho

[issue12625] sporadic test_unittest failure

Charles-François Natali added the comment: > Please write a function (in test.support?) with a comment explaining why you > are doing that. > You may also only do this workaround on specific platforms. For example, > only on FreeBSD and OpenIndiana (the test would be in the functio

[issue12463] Calling SocketServer.shutdown() when server_forever() was not called will hang

Charles-François Natali added the comment: Seems reasonable to me. What bothers me is this comment in shutdown's docstring: """Stops the serve_forever loop. Blocks until the loop has finished. This must be called while serve_forever() is running i

[issue6419] Broken test_kqueue.py on OpenBSD

Charles-François Natali added the comment: Stephan, did you apply the patch? I think the failures you were experiencing on amd64 could be due to issue #12181: OpenBSD's struct kevent definition differs from FreeBSD/NetBSD, which can trigger a segfault on sparc64 (which doesn&#x

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: I'm not sure I see what the problem is: - if the idea behind this is the risk of symlink attack (like issue #4489), it's not the case here, because the directory is created with 0600 permission - furthermore, the attached patch has a TO

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

Charles-François Natali added the comment: The attached patch bumps the barrier's default timeout to 300ms: it should be more than enough (unless you got a really crappy scheduler, or a really heavily loaded machine), especially since this problem doesn't seem to occur ofte

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: > I agree with Antoine - it's a simple bug Alright, in that case I agree (I thought this was considered as a security issue). Two comments on the patch: Lib/tempfile.py: # Don't recurse to symlinked directories (issue #12464)

[issue3526] Customized malloc implementation on SunOS and AIX

Charles-François Natali added the comment: > Fortunately, it is easy to solve by defining the following in > dlmalloc: > #define HAVE_MORECORE 0 I was expecting this answer ;-) Here's a quick demo, on a Linux box: cf@neobox:~/cpython$ ./python Tools/pybench/p

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: > If someone suggests how to test for the Windows version, I'll update > the patch, also to remove the issue reference from the code. Well, I don't know Windows, but there's platform.win32_ver() (http://docs.python.org/

[issue12463] Calling SocketServer.shutdown() when server_forever() was not called will hang

Charles-François Natali added the comment: When you join a thread which hasn't been started, you get an exception, not a deadlock. When you join a newly-created queue, it doesn't wait until an item is submitted to the queue. But honestly I don't really care, since it's such

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > patch-Modules_selectmodule_c is not enough to fix kqueue_event_init(): it > doesn't catch overflow error on the ident attribute. This patch is not correct. Furthermore, it's another occurrence of something I don't understa

[issue12181] SIGBUS error on OpenBSD (sparc64)

Charles-François Natali added the comment: > I wrote the patch. While the patch fixes most of the issues I'm not entirely > happy with it and that's the reason I have not submitted it. Could you submit it here so that we can help you get it in shape for inclusion? That way w

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: The patch looks good to me. -- ___ Python tracker <http://bugs.python.org/issue12464> ___ ___ Python-bugs-list mailin

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

Charles-François Natali added the comment: Victor, can I commit it? -- ___ Python tracker <http://bugs.python.org/issue11871> ___ ___ Python-bugs-list mailin

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

Charles-François Natali added the comment: Patch attached. -- keywords: +needs review, patch stage: -> patch review versions: +Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22780/chown_hpux.diff ___ Python tracker &l

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

Charles-François Natali added the comment: Committed. Josh, thanks for the report. -- resolution: -> fixed stage: patch review -> committed/rejected ___ Python tracker <http://bugs.python.org/i

[issue12603] pydoc.synopsis breaks if filesystem returns mtime of 0

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

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

Charles-François Natali added the comment: > YES YOU CAN :-) -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.2 ___ Python tracker <http://bugs.python

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: There's indeed a leak in your code, because you don't close the stdout and stderr file descriptors. Try with: subp.terminate() subp.stdout.close() subp.stderr.close() return True And you'll be just fine. The reason

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Alright. I tested this on default, and couldn't reproduce the FD leak. It turned out to be due to another bug, affecting only the code path which calls pure C _posixsubprocess (which is the only implementation left in 3.3, but 3.2 still has the old pur

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