[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

New submission from Charles-François Natali : As noted in issue #12502, test_asyncore only tests AF_INET sockets. With the patch attached, the vast majority of the tests will also be run with AF_UNIX and AF_INET6 sockets (if supported by the host OS). -- components: Tests files

[issue12464] tempfile.TemporaryDirectory.cleanup follows symbolic links

Charles-François Natali added the comment: Committed. Petri, thanks for the patch. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12655] Expose sched.h functions

Charles-François Natali added the comment: I'm +0. It would certainly be fun, but I'm not so sure about the "profit" part. The main usage of the scheduler API is for real-time policies, and I somehow doubt Python is commonly used in this area (but I could be wrong). F

[issue12655] Expose sched.h functions

Charles-François Natali added the comment: > I actually implemented this because I wanted to confine a Python process to a > cpu to prevent keep it from being tossed from core to core. It made sense to > bring the other scheduling functions along for the ride. Why didn't you

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

Changes by Charles-François Natali : Added file: http://bugs.python.org/file22802/test_ayncore.diff ___ Python tracker <http://bugs.python.org/issue12656> ___ ___ Pytho

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

Changes by Charles-François Natali : Removed file: http://bugs.python.org/file22795/test_ayncore.diff ___ Python tracker <http://bugs.python.org/issue12656> ___ ___ Pytho

[issue12760] Add create mode to open()

Charles-François Natali added the comment: See also issue 12105. A couple downsides: - O_EXCL is not necessarily portable (doesn't work well with NFS, maybe not on Windows?) - O_EXCL is useful, as is O_CLOEXEC: to be consistent, we should also end up adding all other commonly-used

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

Charles-François Natali added the comment: 2011/8/16 Dave Malcolm : > So in this case, "sys.platform"'s final digit is reporting the major release > of the kernel running outside the chroot-ed build environment (ironically > bearing even less relationship to that

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

Charles-François Natali added the comment: > My question too!  I would say that stable releases should probably not get > this change, but should force sys.platform to linux2 on 3.x kernels. > The point is precisely that we don't change anything: applications checking against sy

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > The "#ifdef O_EXCL" in the source code is probably very old. Copying a > message I posted on python-ideas: > > O_EXCL is a POSIX standard. It is also supported > under Windows by the _open/_wopen compatibility functions (wh

[issue12775] immense performance problems related to the garbage collector

Charles-François Natali added the comment: There's been some work done on the GC some time ago to address this type of pattern (I think to reduce from quadratic complexity to amortized linear complexity). I'm adding Antoine and Martin who were involved in this. > Here is a

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > Yeah, but I think "exclusively" is quite misleading since it does not > perform any locking of any kind. It might be misleading, but I find it clear enough, and this name has been endorsed by POSIX. Furthermore, there's an

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

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

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Patch committed. This should also fix the original problem. Gabriele, thanks for the report. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python track

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Reopening. The new tests are failing on solaris and Debian parallel buildbots: http://www.python.org/dev/buildbot/all/builders/x86 debian parallel 3.x/builds/2734/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/sparc solaris10

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: > This means that the child process didn't get reaped by _cleanup(). The most likely cause is that when _cleanup() calls waitpid(pid, WNOHANG), the child process hasn't exited yet. Since I had already set a rather high timeout to avoid

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: The test now passes on the buildbots, closing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issu

[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param

New submission from Charles-François Natali : http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1734/steps/test/logs/stdio """ == ERROR: test_get_and_set_sche

[issue12786] subprocess wait() hangs when stdin is closed

Charles-François Natali added the comment: Hello Idan, > The following program hangs on Debian Debian is a good choice :-) Concerning your example, it hangs is because the file descriptor used to communicate with proc1 is inherited when proc2 is created (FDs are inherited upon fork

[issue12786] subprocess wait() hangs when stdin is closed

Charles-François Natali added the comment: Here's a patch + test for 2.7. > Really? This is on gentoo, not debian, admittedly: That's because the change of close_fds to True by default and the CLOEXEC flag were added in 3.2. Since 3.1 is in security-fix mode only, this patch is

[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param

Charles-François Natali added the comment: Here's a patch skipping this part of the test on FreeBSD (it actually also fails on FreeBSD 7.2). Note that while calling sched_setparam(param) results in EINVAL with SCHED_OTHER processes, calling sched_setscheduler(SCHED_OTHER, param) works

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Charles-François Natali added the comment: > I looked at multiprocessing code, but didn't understand how to trigger a > call to these functions. Makes it hard to come up with a unit test... Here's a sample test: """ import _multiprocessing import os import

[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param

Charles-François Natali added the comment: The test now passes on FreeBSD buildbots. Closing. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Charles-François Natali added the comment: > Charles; you have +commit, it seems. Yeah, I could of course do this myself, but since Petri already submitted a patch and seemed to be willing to update it with a test, I thought he might be interested in this (I've also seen he's par

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

Charles-François Natali added the comment: > New changeset c64216addd7f by Nick Coghlan in branch 'default': > Add support for the send/recvmsg API to the socket module. Patch by David > Watson and Heiko Wundram. (Closes #6560) > http://hg.python.org/cpython/rev/c64216ad

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Charles-François Natali added the comment: > I'm fine if you fix it, as I'm currently really short on time myself. OK, I'll go ahead. > For 3.3, it may be relevant that send/recvmsg are now available via the > socket API (see #6560). Indeed. We might still need C c

[issue12821] test_fcntl failed on OpenBSD 5.x

Charles-François Natali added the comment: Note that it's been fixed in default with the recent sys.platform refactoring: 26 if (sys.platform.startswith(('netbsd', 'freebsd', 'openbsd', 'bsdos')) 27 or sys.platform == 'dar

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

Charles-François Natali added the comment: > However, in doing this, I noticed that these methods will, at best, work > during the time between connection and the socket going secure and were not > added to the list of methods that the SSL is documented as exposing. Perhaps > we

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > /usr/tmp is not (used) on OpenBSD. How is that a problem? Those are just possible temporary directories to try, so if it doesn't exist, it won't be used (typically ENOENT will be catched when opening a tmpfile). Also, since it's l

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > Because it's not exactly a bug, can you only apply the patch to Python 3.3? Well, we could, but: - it doesn't fix a bug - it doesn't bring any obvious benefit (performance, security, etc) - it introduces an OS-specific case for n

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > We can keep this patch in our tree, I understand your position. I could be missing something, but why do you have this patch in the first place? If it turns out to be useful, then it's of course better to include it upstream, I just don&#x

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

Charles-François Natali added the comment: > it seems that this patch could be safely removed from our port tree. Alright, I'm closing then. > Thanks for all information. And thanks for your help and bug reports concerning OpenBSD-specific issues! -- resolution: ->

[issue12821] test_fcntl failed on OpenBSD 5.x

Charles-François Natali added the comment: Committed to 3.2 and 2.7. Rémi, thanks for the report. -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

Charles-François Natali added the comment: > Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL > because settimeofday() may break the pthread_cond_timedwait(). Indeed. A couple remarks: - regular locks and conditions variables exposed by the threading module suffer

[issue12810] Remove check for negative unsigned value in socketmodule.c

Charles-François Natali added the comment: Thanks. I'll commit this patch tomorrow. I noticed you didn't indicate your full name: do you mind being listed in Misc/ACKS? -- components: +Extension Modules keywords: +easy nosy: +neologix stage: -> commit review type:

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

Charles-François Natali added the comment: Here's a patch skipping testFDPassSeparate and testFDPassSeparateMinSpace on OS X < 10.5, due to known kernel bugs (see http://developer.apple.com/library/mac/#qa/qa1541/_index.html). For InterruptedSendTimeoutTest and testInterruptedSendmsgTim

[issue12333] test_packaging failures under Solaris

Charles-François Natali added the comment: More occurrences: http://www.python.org/dev/buildbot/all/builders/sparc solaris10 gcc 3.x/builds/3555/steps/test/logs/stdio """ == ERROR: test_re

[issue12810] Remove check for negative unsigned value in socketmodule.c

Charles-François Natali added the comment: Patch committed. Thanks Joel! -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

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

Charles-François Natali added the comment: As noted by Antoine, the OS X 10.5 buildbots are also failing. -- ___ Python tracker <http://bugs.python.org/issue6

[issue12786] subprocess wait() hangs when stdin is closed

Changes by Charles-François Natali : -- nosy: +pitrou, rosslagerwall ___ Python tracker <http://bugs.python.org/issue12786> ___ ___ Python-bugs-list mailin

[issue12760] Add create mode to open()

Charles-François Natali added the comment: So, what was the conclusion of the discussion brought up on python-dev? I had a feeling some core devs were opposed to this (I'm personally -0). -- ___ Python tracker <http://bugs.python.org/is

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

Charles-François Natali added the comment: So, what should I do with is_selectable.diff? -- ___ Python tracker <http://bugs.python.org/issue12287> ___ ___ Pytho

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

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

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

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

[issue6419] Broken test_kqueue.py on OpenBSD

Charles-François Natali added the comment: Rémi, can you reproduce this problem? Could you test the patch attached? (It's maybe already part of OPenBSD's tree, in which case it would certainly be nice to include it). -- nosy: +rpointel

[issue12801] C realpath not used by os.path.realpath

Charles-François Natali added the comment: > It would probably be simpler, safer and more efficient to simply call > the POSIX function instead (but it most be exposed somewhere, by > posixmodule.c I suppose). Indeed. > Would it be a good idea to use the full docstring of posixp

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > I haven't seen any discussion on python-dev. Have I missed something? It was on Python-ideas actually: http://mail.python.org/pipermail/python-ideas/2011-August/011183.html -- ___ Python tracke

[issue12786] subprocess wait() hangs when stdin is closed

Charles-François Natali added the comment: With comment. I'll add a similar comment to default. -- Added file: http://bugs.python.org/file23032/subprocess_cloexec-1.diff ___ Python tracker <http://bugs.python.org/is

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

Charles-François Natali added the comment: New patch. > Perhaps bind_af_aware() should find its place in test.support. I'm not sure, it's really specific to this test. > Also, using test.support.unlink means it filters out acceptable errnos. Thanks, I didn't know about

[issue12801] C realpath not used by os.path.realpath

Charles-François Natali added the comment: > Patch to get #ifdef REALPATH_SUPPORT_NULL: I'm not really familiar with autotools, but I have the impression that this will only check that the given code snippet compiles (and it will), and we want to check that a NULL buffer is supp

[issue12837] Patch for issue #12810 removed a valid check on socket ancillary data

Charles-François Natali added the comment: > I included this test deliberately, because msg_controllen may be > of signed type [...] POSIX allows socklen_t to be signed http://pubs.opengroup.org/onlinepubs/007908799/xns/syssocket.h.html """ makes available a type, s

[issue12837] Patch for issue #12810 removed a valid check on socket ancillary data

Charles-François Natali added the comment: I checked in glibc, FreeBSD and OpenBSD source codes, and they all define socklen_t as an unsigned integer. I think the confusion arises from this: """ The third argument of accept() was originally declared as an int * (and

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

Charles-François Natali added the comment: > Using chown_hpux-4.diff, we don't skip anything on HP-UX. Victor, I don't understand your patch: if we try chown()ing a file to root, then this will fail on HP-UX (because chown won't fail with EPERM). That's the w

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

Charles-François Natali added the comment: Well, IIRC, I read in the Solaris man pages that it behaves like HP-UX in this regard. But this it can be changed with `setprivgrp`, so it might work on some machines, and fail on others. According to http://unix.derkeiler.com/Newsgroups

[issue12835] Missing SSLSocket.sendmsg() wrapper allows programs to send unencrypted data by mistake

Changes by Charles-François Natali : -- nosy: +ncoghlan, pitrou priority: normal -> high type: -> behavior ___ Python tracker <http://bugs.python.org/i

[issue12656] test.test_asyncore: add tests for AF_INET6 and AF_UNIX sockets

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

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

Charles-François Natali added the comment: > The OS X buildbots show some failures: It seems to fail consistently on every OS X version. I've had another look both at the code and the test, and couldn't find anything wrong with it. Since there are a number of known bugs per

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

Charles-François Natali added the comment: > Oooh, I'm confused. I removed this stupid patch. chown_hpux-3.diff has a problem too: it skips the successful chown call (that's why I put the SkipTest at the end). -- ___ Python t

[issue12786] subprocess wait() hangs when stdin is closed

Charles-François Natali added the comment: Patch committed. Idan, thanks for the report. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

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

Charles-François Natali added the comment: > "Avoid sending very large amounts of data via queues, as you could come up > against system-dependent limits according to the operating system and whether > pipes or sockets are used. You could consider an alternative strategy, such

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

Charles-François Natali added the comment: > STINNER Victor added the comment: > > The _socket module doesn't compile anymore on Windows: > Fixed (that's why I wanted a Windows expert to have a look at this patch :-). > You might replace "#if define

[issue12837] Patch for issue #12810 removed a valid check on socket ancillary data

Charles-François Natali added the comment: > That has since been changed. I'm reading from POSIX.1-2008, > which says: I see. > The warning against using values larger than 2**32 - 1 is still > there, I presume because they would not fit in a 32-bit signed > int. I assum

[issue12837] Patch for issue #12810 removed a valid check on socket ancillary data

Charles-François Natali added the comment: Thanks for the patch. For the record, here's Linus Torvalds' opinion on this whole socklen_t confusion: """ _Any_ sane library _must_ have "socklen_t" be the same size as int. Anything else breaks any BSD socke

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

Changes by Charles-François Natali : -- components: +Documentation -Library (Lib) nosy: +docs@python priority: normal -> low ___ Python tracker <http://bugs.python.org/iss

[issue4028] Problem compiling the multiprocessing module on sunos5

Charles-François Natali added the comment: Hello, > there's some issues compiling the multiprocessing module on the SunOS > I have here, where CMSG_LEN, CMSG_ALIGN, CMSG_SPACE and sem_timedwait > are absent. CMSG_LEN and friends should be defined by (as required by POSIX).

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

Charles-François Natali added the comment: Alright, committed to 2.7, 3.2 an default. Seems to work on all the buildbots, closing. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python track

[issue12801] C realpath not used by os.path.realpath

Charles-François Natali added the comment: > Well, if we use two different paths based on the libc version, it might not > be a good idea, since behaviour can be different in some cases. Indeed. > It would be nice to know if some modern platforms have a non-compliant > realpath(

[issue12801] C realpath not used by os.path.realpath

Charles-François Natali added the comment: > POSIX the standard, or the implementers?? > Both :-) For those wondering why we can't use PATH_MAX (ignoring the buffer overallocation), here's why: https://www.securecoding.cert.org/confluence/display/cplusplus/FIO02-CPP.+Canonic

[issue12852] test_posix.test_fdlistdir() segfault on OpenBSD

Charles-François Natali added the comment: [Switching to process 21658, thread 0x20a519000] _readdir_unlocked (dirp=0xafb0e80, result=0x7f7d7ac0, skipdeleted=1) at /usr/src/lib/libc/gen/readdir.c:44 44 if (dirp->dd_loc >= dirp->dd_size) Looks like dirp

[issue12852] test_posix.test_fdlistdir() segfault on OpenBSD

Charles-François Natali added the comment: > I think that the problem is that fdopendir() is not defined. If a function is > not defined, C uses int as the result type. An int is not enough to store a > 64-bit pointer. See in gdb output: dirp is 0x0afb0e80 whereas other pointers &g

[issue1462440] socket and threading: udp multicast setsockopt fails

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

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

Charles-François Natali added the comment: OpenBSD's threads are userland threads, and sigaltstack() doesn't work when the program is built with -pthread: http://marc.info/?l=openbsd-bugs&m=114323355014696&w=2 Note that POSIX warns about this: http://www.opengroup.org/on

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

Changes by Charles-François Natali : -- keywords: +patch Added file: http://bugs.python.org/file23078/openbsd_sigaltstack.diff ___ Python tracker <http://bugs.python.org/issue12

[issue12871] Disable sched_get_priority_min/max if Python is compiled without threads

Charles-François Natali added the comment: There's no reason to disable sched_get_priority_(min|max) when Python is built without threads: those libraries control the scheduling policy, and should be available even without pthread. However, it's really likely that pthread h

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

Charles-François Natali added the comment: > It does not build completely, I have a problem if I add > --without-threads: Until this gets fixed, if you want to do a quick test, you could just remove the calls to sched_get_priority_(min|max): """ diff -r 0968acf0e6db

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

Charles-François Natali added the comment: > Anyway, since my view does not seem to resonate with core developers I I'll > give it a rest for now. Well, the problem is that many views have been expressed in this thread, which doesn't help getting a clear picture of what&

[issue12472] Build failure on IRIX

Charles-François Natali added the comment: I'm closing, since IRIX header files seem terminally broken, and we can't do much about it. Furthermore, I'm 99% sure IRIX isn't officially supported anymore. -- resolution: -> wont fix stage: -> committed/rejec

[issue12837] Patch for issue #12810 removed a valid check on socket ancillary data

Charles-François Natali added the comment: `long long` is not ANSI, but C99. Anyhow, I'm still not sure this check is necessary, because: 1) I really doubt any modern OS uses a signed socklen_t 2) even if it's the case, I don't see how we could possibly end up with a negative

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

Charles-François Natali added the comment: > without-threads, it segfault: > It's normal :-) _stack_overflow triggers - as it names implies - a stack overflow. However, as you can see in the output, faulthandler is now able to catch the SIGSEGV and display the backtrace (because i

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

Charles-François Natali added the comment: Here's a patch with an updated skip message. As for rthreads support, a quick search seems to indicate that its API is exactly the same as pthreads, and it's even binary compatible. Python will automatically use it when run on a OpenBSD s

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

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

[issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD

Charles-François Natali added the comment: Committed. Rémi, thanks once again for this report! -- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12871] Disable sched_get_priority_min/max if Python is compiled without threads

Charles-François Natali added the comment: > It builds correctly with -pthread or -lpthread, but it fails to build without > these options. > Not on Linux: this is specific to OpenBSD. > sched_get_priority_max() and sched_get_priority_min() come from libpthread on > OpenBSD,

[issue12882] mmap crash on Windows

Changes by Charles-François Natali : -- Removed message: http://bugs.python.org/msg143397 ___ Python tracker <http://bugs.python.org/issue12882> ___ ___ Python-bug

[issue12871] Disable sched_get_priority_min/max if Python is compiled without threads

Charles-François Natali added the comment: Here's a patch adding a configure-time check. Since the functions are checked without being linked explicitely with pthread, it should do the trick (I couldn't test it on OpenBSD though). I also added a skipTest to test_posix.test_sche

[issue12905] multiple errors in test_socket on OpenBSD

Charles-François Natali added the comment: > I hope that this issue is not related to threads+signals. We got many > threads+signals issues on FreeBSD 6. Yep. OpenBSD has a really specific pthread implementation (in user-space, using non-blocking I/O), so it might very well be "

[issue12871] Disable sched_get_priority_min/max if Python is compiled without threads

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

[issue12905] multiple errors in test_socket on OpenBSD

Charles-François Natali added the comment: > Hi, it blocks too: Oops, I just realized there was a typo in the sample test. The signal handler should be lambda x,y: 1/0 and not lambda x,y: 0 -- ___ Python tracker <http://bugs.pyth

[issue12905] multiple errors in test_socket on OpenBSD

Charles-François Natali added the comment: > The C signal handler is called, but the system call (read in this case) > is not interrupted. That's what I thought... > Bad news: the script doesn't hang if Python is build without threads. Makes sense. When linked with pthrea

[issue12905] multiple errors in test_socket on OpenBSD

Charles-François Natali added the comment: > Using SA_RESTART, read() is not interrupted. But if the program is linked to > pthread, read() is always interrupted: with sa_flags=0 or sa_flags=SA_RESTART. > Ouch... >> But OpenBSD's pthread implementation has sev

[issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0

Charles-François Natali added the comment: > this is the result of gcc -E on Modules/posixmodule.o, asked by haypo. And this confirms that __POSIX_VISIBLE < 200809 when is included, hence the missing prototype. > I suppose that there is a conflict between Python's _POSI

[issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0

Charles-François Natali added the comment: > _POSIX_C_SOURCE value is set automatically depending on _XOPEN_SOURCE > value. I know, but I think it's better to be consistent an also bump _POSIX_C_SOURCE to POSIX 2008, and follow POSIX's recommandation (http://pubs.opengrou

[issue12905] multiple errors in test_socket on OpenBSD

Charles-François Natali added the comment: > It looks like Python cannot do much to workaround OpenBSD issues. IMO the > best fix is just to skip these tests on OpenBSD, until OpenBSD handles > correctly signals in programs linked to pthread. The same "fix" can be used &g

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali added the comment: You don't have a core dump, do you? -- nosy: +neologix ___ Python tracker <http://bugs.python.org/issue12936> ___ ___

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali added the comment: > No such luck. Somehow gdb doesn't dump the core file: What do $ /sbin/sysctl -a | grep "kernel.core" And $ grep core /etc/security/limits.conf return? -- ___ Python tracker <h

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali added the comment: > Traceback with faulthandler disabled: It crashes when trying to look up TLS (which explains why it doesn't crash when built ``without-threads`). Looks like a libc bug, but would it be possible to have a backtrace with Python built wi

[issue12936] armv5tejl: random segfaults in getaddrinfo()

Charles-François Natali added the comment: > Could faulthandler cause problems like these: Well, that would explain why it crashes in the TLS lookup code, and why the core dump looks borked. 1) Apparently, Etch on ARM uses linuxthread instead of NPTL: what does $ getc

[issue11912] PaX triggers a segfault in dlopen

Charles-François Natali 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 mprot

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

Charles-François Natali 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 designed and merged),

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

Charles-François Natali 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 ;-) >

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