Charles-François Natali neolo...@free.fr 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 sys/socket.h (as required
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - invalid
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1462440
Charles-François Natali neolo...@free.fr 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-bugsm=114323355014696w=2
Note that POSIX warns about this:
http://www.opengroup.org/onlinepubs
Changes by Charles-François Natali neolo...@free.fr:
--
keywords: +patch
Added file: http://bugs.python.org/file23078/openbsd_sigaltstack.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12868
Charles-François Natali neolo...@free.fr 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 has
Charles-François Natali neolo...@free.fr 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 Modules
Charles-François Natali neolo...@free.fr 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's needed
Charles-François Natali neolo...@free.fr 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/rejected
status
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23078/openbsd_sigaltstack.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12868
Charles-François Natali neolo...@free.fr added the comment:
Committed.
Rémi, thanks once again for this report!
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Charles-François Natali neolo...@free.fr 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
Changes by Charles-François Natali neolo...@free.fr:
--
Removed message: http://bugs.python.org/msg143397
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12882
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
type: - compile error
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12871
Charles-François Natali neolo...@free.fr 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 rep
Charles-François Natali neolo...@free.fr 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 pthread, all
Charles-François Natali neolo...@free.fr 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 severe limitations/bugs
Charles-François Natali neolo...@free.fr 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 dirent.h is included,
hence the missing prototype.
I suppose that there is a conflict between Python's
Charles-François Natali neolo...@free.fr 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.opengroup.org
Charles-François Natali neolo...@free.fr 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
for #12903
Charles-François Natali neolo...@free.fr added the comment:
You don't have a core dump, do you?
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12936
Charles-François Natali neolo...@free.fr 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 rep
Charles-François Natali neolo...@free.fr 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
Charles-François Natali neolo...@free.fr 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
$ getconf
Charles-François Natali neolo...@free.fr added the comment:
Looks good to me.
--
nosy: +neologix
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12881
Charles-François Natali neolo...@free.fr added the comment:
2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453
We actually had another issue due to this particular libc bug:
http://bugs.python.org/issue6059
Basically, the problem is that if some libraries are dynamically
loaded
Charles-François Natali neolo...@free.fr added the comment:
Oh, and BTW, for the Backtrace stopped: frame did not save the PC, you might
want to install the libc-dbg package. This might help in finding precisely
where it's crashing.
--
___
Python
Charles-François Natali neolo...@free.fr added the comment:
I think I got it: pthread_setaffinity_np() does not crash.
Nice.
Out of curiosity, I just looked at the source code, and it just does
sched_setaffinity(thread-tid), so you can do the same with
sched_setaffinity(syscall(SYS_gettid
Charles-François Natali neolo...@free.fr added the comment:
If we have access (and as I understood from Victor's post we do):
pthread_getaffinity_np() also exists on FreeBSD, which would be
an advantage.
Yes, but I see several drawbacks:
- as noted by Victor, it's really easy to crash
Charles-François Natali neolo...@free.fr added the comment:
Do you mean that signal.pthread_kill() should be removed? This function is
very useful and solve some issues that cannot be solved differently. At the
same time, I don't think that it's possible to workaround the crashes
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12975
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23150/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12975
Charles-François Natali neolo...@free.fr added the comment:
According to the following article, a fsync is also needed on the
directory after a rename. I don't understand if is it always needed for
an atomic rename, or if we only need it for the atomic write pattern.
It's not needed if you
Charles-François Natali neolo...@free.fr added the comment:
I'd prefer to disable the misbehaving functions entirely on arm.
-10
If we start disabling features on platforms with partly bogus implementations,
we might as well drop threading on OpenBSD, sendmsg() on OS-X, etc.
Furthermore
Charles-François Natali neolo...@free.fr added the comment:
Hello,
According to http://fxr.watson.org/fxr/ident?v=NETBSD;im=3;i=EVFILT_TIMER
EVFILT_TIMER is defined on NetBSD.
As for MirBSD, with all due respect, it really looks like a niche platform,
definitely not officially supported
Charles-François Natali neolo...@free.fr added the comment:
Since this patch alone won't be enough to support MirBSD (and is required only
for MirBSD), I suggest you to post the complete patch, and rename this issue
add support for MirBSD platform, or something along those lines.
That way, we
New submission from Charles-François Natali neolo...@free.fr:
Now that sendmsg()/recvmsg() are exposed in socketmodule, we could use them to
replace the ad-hoc FD-passing routines used by multiprocessing.reduction.
Antoine suggested adding sendfd()/recvfd() methods to socket objects, but I'm
Charles-François Natali neolo...@free.fr added the comment:
I don't think that it's a problem to remove private functions.
Alright.
Is it mandatory to send a non-empty message (first argument for sendmsg, b'x'
in your patch)? The original C function sends a random byte :-)
Some
Changes by Charles-François Natali neolo...@free.fr:
Added file: http://bugs.python.org/file23166/multiprocessing_fd-1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12981
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23156/multiprocessing_fd.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12981
Charles-François Natali neolo...@free.fr added the comment:
I only tried on Linux.
By the way, what's the simplest way to create a personal clone to test patches
on some of the buildbots before committing them?
--
___
Python tracker rep
Charles-François Natali neolo...@free.fr added the comment:
It's a dupe of issue #8426: the Queue isn't full, but the underlying pipe is,
so the feeder thread blocks on the write to the pipe (actually when trying to
acquire the lock protecting the pipe from concurrent access).
Since
New submission from Charles-François Natali neolo...@free.fr:
Since the rewrite in pure Python of multiprocessing.Connection (issue #11743),
multiprocessing.Connection sends and receives the length of the data (used as
header) in host byte order.
This will break if the connection's endpoints
Changes by Charles-François Natali neolo...@free.fr:
--
nosy: haypo, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: _XOPEN_SOURCE usage on Solaris
type: behavior
versions: Python 3.3
___
Python tracker rep
New submission from Charles-François Natali neolo...@free.fr:
While testing issue #12981, I stumbled on a problem on OpenIndiana buildbot:
test test_multiprocessing crashed -- Traceback (most recent call last):
File
/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/test
Charles-François Natali neolo...@free.fr added the comment:
Did you try it on Linux, FreeBSD and/or Windows?
It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see
issue #12999.
--
dependencies: +_XOPEN_SOURCE usage on Solaris
Charles-François Natali neolo...@free.fr added the comment:
Hello Benny,
As requested, here is the full patch for MirBSD support. The diff was taken
against version 2.7.2. It is really quite easy, you just need to handle
MirBSD like OpenBSD.
With this patch, I can successfully compile
Charles-François Natali neolo...@free.fr added the comment:
Here's a patch taking into account the fact that
multiprocessing.reduction might not be available and importing it can
raise an ImportError (which is already the case with the C
implementation, but multiprocessing.reduction tests have
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23166/multiprocessing_fd-1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12981
New submission from Charles-François Natali neolo...@free.fr:
http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2
3.x/builds/2129/steps/test/logs/stdio
==
FAIL: testRecvmsgTrunc (test.test_socket.RecvmsgUDPTest
Charles-François Natali neolo...@free.fr added the comment:
Since the rewrite in pure Python of multiprocessing.Connection (issue
#11743), multiprocessing.Connection sends and receives the length of the data
(used as header) in host byte order.
I don't think so, the C code uses also
Charles-François Natali neolo...@free.fr added the comment:
It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see
issue #12999.
Oh, thank for testing before committing :) It's hard to debug multiprocessing.
Yes. Especially when you stumble upon a kernel/libc bug 25
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23180/multiprocessing_fd-2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12981
Charles-François Natali neolo...@free.fr added the comment:
I had a look at this patch, and the FD passing looked OK, except
that calculating the buffer size with CMSG_SPACE() may allow more
than one file descriptor to be received, with the extra one going
unnoticed - it should use CMSG_LEN
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12996
Charles-François Natali neolo...@free.fr added the comment:
I committed the patch to catch the ImportError in test_multiprocessing.
I'll commit the other patch (pure Python version) in a couple days.
Ah, no, you're right - that's fine. Sorry for the false alarm.
No problem. As they say
Charles-François Natali neolo...@free.fr added the comment:
The patch includes a test case, but like the other recently-added
tests for the function, it isn't guarded against
multiprocessing.reduction being unavailable. Issue #12981 has a
patch skip_reduction.diff (already in 3.3) to fix
Charles-François Natali neolo...@free.fr added the comment:
Here's an updated patch, with more tests.
Please review!
--
keywords: +needs review
nosy: +haypo
stage: patch review - commit review
Added file: http://bugs.python.org/file23225/socketcan_v4.patch
Charles-François Natali neolo...@free.fr added the comment:
- dummy question: why an address is a tuple with 1 string instead of just
the string? Does AF_UNIX also uses a tuple of 1 string?
I think the reason behind the tuple is future proofing.
Here's the definition of `struct sockaddr_can
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23225/socketcan_v4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10141
Changes by Charles-François Natali neolo...@free.fr:
--
dependencies: -_XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
resolution: - fixed
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Charles-François Natali neolo...@free.fr:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12981
___
___
Python
Charles-François Natali neolo...@free.fr added the comment:
Patch applied, thanks!
--
nosy: +neologix
resolution: - fixed
stage: - committed/rejected
status: open - closed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4
___
Python tracker
Charles-François Natali neolo...@free.fr added the comment:
Confirmed with default.
The problem is that the TextIOWrapper gets collected after the underlying
BufferedRWPair has been cleared (tp_clear) by the garbage collector: when
_PyIOBase_finalize() is called for the TextIOWrapper
Charles-François Natali neolo...@free.fr added the comment:
With test.
--
Added file: http://bugs.python.org/file23278/buffered_closed_gc-1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13070
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23277/buffered_closed_gc.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13070
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23278/buffered_closed_gc-1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13070
Changes by Charles-François Natali neolo...@free.fr:
Added file: http://bugs.python.org/file23279/buffered_closed_gc-1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13070
Charles-François Natali neolo...@free.fr added the comment:
See http://bugs.python.org/issue12469, specifically
http://bugs.python.org/issue12469#msg139831
When signals are unblocked, pending signal ared delivered in the reverse
order
of their number (also on Linux, not only on FreeBSD
Changes by Charles-François Natali neolo...@free.fr:
--
keywords: +patch
Added file: http://bugs.python.org/file23284/check_signum_order.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13084
Charles-François Natali neolo...@free.fr added the comment:
Shouldn't the test use self.BufferedRWPair instead of
io.BufferedRWPair?
Yes.
Also, is it ok to just return NULL or should the error state also be
set?
Well, I'm not sure, that why I made you and Amaury noisy :-)
AFAICT
Changes by Charles-François Natali neolo...@free.fr:
Removed file: http://bugs.python.org/file23279/buffered_closed_gc-1.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13070
Charles-François Natali neolo...@free.fr added the comment:
@requires_freebsd_version should be factorized with
@requires_linux_version.
Patches attached.
Can we workaround FreeBSD ( 8) bug in C/Python?
Not really.
Or should we remove the function on FreeBSD 8?
There's really no reason
Charles-François Natali neolo...@free.fr added the comment:
So, Victor, what do you think of the last version?
This patch has been lingering for quite some time, and it's really a
cool feature.
--
___
Python tracker rep...@bugs.python.org
http
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13084
Charles-François Natali neolo...@free.fr added the comment:
Hello,
method:: socket.getsockopt(level, optname[, optarg])
The overloading of the third parameter is confusing: it can already be an
integer value or a buffer size, I don't think that adding a third possibility
is a good idea
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13001
Charles-François Natali neolo...@free.fr added the comment:
test_multiprocessing frequently hangs on FreeBSD 8 buildbots, and this
probably has to do with the limit on the max number of POSIX semaphores:
==
ERROR
Charles-François Natali neolo...@free.fr added the comment:
Probably. OTOH, not setting the error state when returning NULL is
usually an error (and can result in difficult-to-debug problems), so
let's stay on the safe side.
RuntimeError perhaps.
OK, I'll update the patch accordingly
Charles-François Natali neolo...@free.fr added the comment:
-1
IMHO, implementing SysV semaphores would be a step backwards, plus the API is a
real pain.
I think there's no reason to complicate the code to accomodate such corner
cases, especially since the systems that don't support POSIX
Charles-François Natali neolo...@free.fr added the comment:
Sorry, forgot about this issue...
Updated patch (I'm not really satisfied with the error message, don't
hesitate if you can think of a better wording).
--
Added file: http://bugs.python.org/file23319/buffered_closed_gc-3.diff
Charles-François Natali neolo...@free.fr added the comment:
I've attached an update for the previous patch. Now there's no more
overloading for the third argument and socket.getsockopt accepts one more
optional argument -- a buffer to use as an input to kernel.
Remarks:
+ length
Changes by Charles-François Natali neolo...@free.fr:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10141
___
___
Python-bugs-list
Changes by Charles-François Natali neolo...@free.fr:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11956
Charles-François Natali neolo...@free.fr added the comment:
I don't have much to say about the patch, given that I don't know
anything about CAN and my system doesn't appear to have a vcan0
interface.
I had never heard about it before this issue, but the protocol is really simple.
If you
Charles-François Natali neolo...@free.fr added the comment:
Committed to 3.2 and default.
Victor, thanks for the report!
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Charles-François Natali neolo...@free.fr added the comment:
The issue doesn't affect Python 2.7?
Duh!
I was sure the _io module had been introduced in Python 3 (I/O layer
rewrite, etc).
Yes, it does apply to 2.7. I'll commit the patch later today
Charles-François Natali neolo...@free.fr added the comment:
Wouldn't it be better to add an 'ignore' option to the copy_tree() method with
an optional list of patterns to ignore instead of hardcoding '.nsfXXX' files?
This would make it possible to also skip '.hg', 'CVS' artifacts
Charles-François Natali neolo...@free.fr added the comment:
I guess this is the magic in mkdir -p:
mkdir(expert, 0755) = -1 EACCES (Permission denied)
chdir(expert) = 0
mkdir(tmp, 0755) = -1 EEXIST (File exists)
I'm not sure
Charles-François Natali neolo...@free.fr added the comment:
Yes, creating the directories in a bottom-up way (i.e. '/net', '/net/prodigy',
'/net/prodigy/foo') could maybe avoid this problem.
But this is definietely an autofs bug, and there are probably many other places
where such code might
Charles-François Natali neolo...@free.fr added the comment:
Alright, closing for good then.
Andrew, if you want to get this fixed, you should report this to the autofs
folks, because it's definitely not a Python bug.
--
stage: - committed/rejected
status: open - closed
801 - 900 of 1823 matches
Mail list logo
