Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
Quoting Jung-uk Kim j...@freebsd.org: On Monday 28 June 2010 02:01 pm, Jung-uk Kim wrote: Please drop the attached patch in ports/devel/boost-libs/files, rebuild all dependencies, and try your deluge ports again[1]. Please ignore the previous patch and try this one. Sorry, there was a typo. :-( I updated boost-libs with your patch which fixed the issue. I no longer have the ioctl warning. :) 1) I rebuilt the libtorrent-rasterbar-14 then libtorrent-rasterbar-14-python. 2) Tried deluge, there were warnings still. 3) Then, rebuilt deluge. 4) Tried deluge, warnings were gone. I still have the lang/python26 patches you sent earlier. So I have both the python and boost-libs patches on my system. Do you want to me to do any further testing? Regards, -- Mario S F Ferreira - DF - Brazil - I guess this is a signature. feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Tuesday 29 June 2010 12:46 pm, Mario Sergio Fujikawa Ferreira wrote: Quoting Jung-uk Kim j...@freebsd.org: On Monday 28 June 2010 02:01 pm, Jung-uk Kim wrote: Please drop the attached patch in ports/devel/boost-libs/files, rebuild all dependencies, and try your deluge ports again[1]. Please ignore the previous patch and try this one. Sorry, there was a typo. :-( I updated boost-libs with your patch which fixed the issue. I no longer have the ioctl warning. :) 1) I rebuilt the libtorrent-rasterbar-14 then libtorrent-rasterbar-14-python. 2) Tried deluge, there were warnings still. 3) Then, rebuilt deluge. 4) Tried deluge, warnings were gone. I still have the lang/python26 patches you sent earlier. So I have both the python and boost-libs patches on my system. Do you want to me to do any further testing? No, that should be good enough. Thanks for testing my patches! Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Saturday 26 June 2010 05:09 am, Mario Sergio Fujikawa Ferreira
wrote:
On 25/06/2010 18:58, Jung-uk Kim wrote:
On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira
wrote:
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kimj...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
li...@freebsd.org Subject: Re: FreeBSD 8.1-PRERELEASE:
WARNING ioctl sign-extension ioctl 8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira
wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension
ioctl 8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we
need to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in
kernel source code as a workaround.
By the way it seems to be a POSIX violation and we
didn't seem to really use so wide cmd, but I have not
yet verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python
/fil es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ
e=te xt %2 Fpl ain
I believe it was upstream patched at the time but I
won't be surprised if something similar was
reintroduced. It happens when a Python internal
integer type is converted to a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that
it would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s
but didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned
non-checked 'I' format for the 'code' parameter because
Python turns 0x800 into either a large positive number
(PyLong or PyInt on 64-bit platforms) or a negative number on
others (32-bit PyInt) whereas the system expects it to be a
32bit bit field value regardless of it being passed as an int
or unsigned long on various platforms. See the
termios.TIOCSWINSZ constant across platforms for an example
of thise.
If any of the 64bit platforms ever decide to use more
than 32bits in their unsigned long ioctl codes this will
break and need special casing based on the platform being
built on. */
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files
and test. Note I am not a Python guy, so please don't shoot
me. ;-)
I found that Python guys added 'k' format since 2.3, which
converts a Python integer to unsigned long. Please ignore the
previous patch and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6):
ioctl sign-extension ioctl 8004667e
It may be a deeper problen, then. :-(
First of all, I cannot reproduce the problem because deluged
dumps core on my box and I gave it up. Just staring at the code,
it seems they rely on a bundled libtorrent for Python binding and
the libtorrent relies on Boost, in turn. Then, the actual
non-blocking socket implementation is done with Boost ASIO[1].
It is possible that there are more complicated problems between
these and the Python binding. In fact, I can see a lot of these:
int name() const
{
return FIONBIO;
}
...
if (!ec command.name() == static_castint(FIONBIO))
...
socket_ops::ioctl(impl.socket_, command.name(), ...)
...
They are just assuming it is an int type, I guess.
Sigh, what a mess...
Given that your python patch is a step on the right direction, I
would propose that it be further tested and then committed if
possible.
[1] Boost and its Python binding from ports seems to be a newer
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Monday 28 June 2010 02:01 pm, Jung-uk Kim wrote:
Please drop the attached patch in ports/devel/boost-libs/files,
rebuild all dependencies, and try your deluge ports again[1].
Please ignore the previous patch and try this one. Sorry, there was a
typo. :-(
Jung-uk Kim
--- boost/asio/detail/io_control.hpp.orig 2010-01-04 04:36:00.0
-0500
+++ boost/asio/detail/io_control.hpp2010-06-25 18:38:28.0 -0400
@@ -46,7 +46,7 @@ public:
}
// Get the name of the IO control command.
- int name() const
+ ioctl_cmd_type name() const
{
return FIONBIO;
}
@@ -96,7 +96,7 @@ public:
}
// Get the name of the IO control command.
- int name() const
+ ioctl_cmd_type name() const
{
return FIONREAD;
}
--- boost/asio/detail/reactive_descriptor_service.hpp.orig 2010-06-25
18:24:52.0 -0400
+++ boost/asio/detail/reactive_descriptor_service.hpp 2010-06-25
18:56:32.0 -0400
@@ -223,7 +223,7 @@ public:
// descriptor is put into the state that has been requested by the user. If
// the ioctl syscall was successful then we need to update the flags to
// match.
-if (!ec command.name() == static_castint(FIONBIO))
+if (!ec command.name() == static_castioctl_cmd_type(FIONBIO))
{
if (*static_castioctl_arg_type*(command.data()))
{
--- boost/asio/detail/reactive_socket_service.hpp.orig 2010-04-07
04:44:41.0 -0400
+++ boost/asio/detail/reactive_socket_service.hpp 2010-06-25
18:55:06.0 -0400
@@ -453,7 +453,7 @@ public:
// already in the correct state. This ensures that the underlying socket
// is put into the state that has been requested by the user. If the ioctl
// syscall was successful then we need to update the flags to match.
-if (!ec command.name() == static_castint(FIONBIO))
+if (!ec command.name() == static_castioctl_cmd_type(FIONBIO))
{
if (*static_castioctl_arg_type*(command.data()))
{
--- boost/asio/detail/win_iocp_socket_service.hpp.orig 2010-03-29
21:20:37.0 -0400
+++ boost/asio/detail/win_iocp_socket_service.hpp 2010-06-25
18:55:49.0 -0400
@@ -564,7 +564,7 @@ public:
socket_ops::ioctl(impl.socket_, command.name(),
static_castioctl_arg_type*(command.data()), ec);
-if (!ec command.name() == static_castint(FIONBIO))
+if (!ec command.name() == static_castioctl_cmd_type(FIONBIO))
{
if (*static_castioctl_arg_type*(command.data()))
impl.flags_ |= implementation_type::user_set_non_blocking;
--- boost/asio/detail/descriptor_ops.hpp.orig 2010-01-04 04:36:00.0
-0500
+++ boost/asio/detail/descriptor_ops.hpp2010-06-25 18:37:37.0
-0400
@@ -110,7 +110,7 @@ inline int gather_write(int d, const buf
return result;
}
-inline int ioctl(int d, long cmd, ioctl_arg_type* arg,
+inline int ioctl(int d, ioctl_cmd_type cmd, ioctl_arg_type* arg,
boost::system::error_code ec)
{
clear_error(ec);
--- boost/asio/detail/socket_ops.hpp.orig 2010-01-04 06:55:09.0
-0500
+++ boost/asio/detail/socket_ops.hpp2010-06-25 18:39:55.0 -0400
@@ -596,7 +596,7 @@ inline int getsockname(socket_type s, so
return result;
}
-inline int ioctl(socket_type s, long cmd, ioctl_arg_type* arg,
+inline int ioctl(socket_type s, ioctl_cmd_type cmd, ioctl_arg_type* arg,
boost::system::error_code ec)
{
clear_error(ec);
--- boost/asio/detail/socket_types.hpp.orig 2010-03-21 05:39:26.0
-0400
+++ boost/asio/detail/socket_types.hpp 2010-06-25 18:48:43.0 -0400
@@ -189,6 +189,12 @@ typedef sockaddr_in6 sockaddr_in6_type;
typedef sockaddr_storage sockaddr_storage_type;
typedef sockaddr_un sockaddr_un_type;
typedef addrinfo addrinfo_type;
+#if (defined(__MACH__) defined(__APPLE__)) || defined(__DragonFly__) || \
+defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+typedef unsigned long ioctl_cmd_type;
+#else
+typedef int ioctl_cmd_type;
+#endif
typedef int ioctl_arg_type;
typedef uint32_t u_long_type;
typedef uint16_t u_short_type;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 28 Jun 2010, Jung-uk Kim wrote: Please drop the attached patch in ports/devel/boost-libs/files, rebuild all dependencies, and try your deluge ports again[1]. Jung-uk Kim [1] Your libtorrent Python slave port and deluge ports don't build/package cleanly. I guess you need to update the PR's. I'm actually working now on the update for libtorrent-rasterbar-15 and deluge based on the work that lioux did, so I will gladly try your patch (from the 2nd e-mail) and let you know how it goes. I'm currently working with the author of libtorrent to iron out some bugs that we've found while working on the python bindings, and in preparation for his new release of 0.15.1, so hopefully it will all be done later this week. :) Doug - -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMKPNPAAoJEFzGhvEaGryEHPkIAK4DCd6dGtPJHlmTDUkZhBxc CR4GgDi5xTuw5weHzEFLV8l//tXxGBkcMYLMpxH+icakeVkxgBH4J5XIF05fRiYY Nf3pB8/2SZJv+Ni78t105FI98BrtDBuY+sO1cyfdLoy61AVvWPiEdfJYHXSlBLy9 ykmuZWpB6iP93PTtWrdzcTtTC+qA/YEDBa7NevLr9XvsEC7/ocdJgvufUQ8XS/SB baCiU/MwleeuNeHuXxAuXjsVUo0Et7QkoU9yZsdIk5efQRnbsEDyKXfT+h2ti5RO GuEnlW1kx1ldYJIMbqYVDwNfv/fllDWEyKS+36AhF0ZUexUz2Kryew4BsZS5y98= =sBTZ -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On 25/06/2010 18:58, Jung-uk Kim wrote:
On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira wrote:
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kimj...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
li...@freebsd.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING
ioctl sign-extension ioctl 8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira
wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension
ioctl 8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we
need to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in
kernel source code as a workaround.
By the way it seems to be a POSIX violation and we
didn't seem to really use so wide cmd, but I have not
yet verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python
/fil es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ
e=te xt %2 Fpl ain
I believe it was upstream patched at the time but I
won't be surprised if something similar was
reintroduced. It happens when a Python internal
integer type is converted to a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that
it would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s
but didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned
non-checked 'I' format for the 'code' parameter because
Python turns 0x800 into either a large positive number
(PyLong or PyInt on 64-bit platforms) or a negative number on
others (32-bit PyInt) whereas the system expects it to be a
32bit bit field value regardless of it being passed as an int
or unsigned long on various platforms. See the
termios.TIOCSWINSZ constant across platforms for an example
of thise.
If any of the 64bit platforms ever decide to use more
than 32bits in their unsigned long ioctl codes this will
break and need special casing based on the platform being
built on. */
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which
converts a Python integer to unsigned long. Please ignore the
previous patch and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6):
ioctl sign-extension ioctl 8004667e
It may be a deeper problen, then. :-(
First of all, I cannot reproduce the problem because deluged dumps
core on my box and I gave it up. Just staring at the code, it seems
they rely on a bundled libtorrent for Python binding and the
libtorrent relies on Boost, in turn. Then, the actual non-blocking
socket implementation is done with Boost ASIO[1]. It is possible
that there are more complicated problems between these and the Python
binding. In fact, I can see a lot of these:
int name() const
{
return FIONBIO;
}
...
if (!ec command.name() == static_castint(FIONBIO))
...
socket_ops::ioctl(impl.socket_, command.name(), ...)
...
They are just assuming it is an int type, I guess.
Sigh, what a mess...
Given that your python patch is a step on the right direction, I would
propose that it be further tested and then committed if possible.
[1] Boost and its Python binding from ports seems to be a newer ASIO
version than the bundled ASIO headers. Probably it is a reason for
the crash but I didn't bother too much.
If you have the time, everything you need to run the latest deluge
1.3.0 RC1 can be found at
http://www.freebsd.org/cgi/query-pr.cgi?pr=144337
Check
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kim j...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira li...@freebsd.org
Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl
8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we need
to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in kernel
source code as a workaround.
By the way it seems to be a POSIX violation and we didn't
seem to really use so wide cmd, but I have not yet
verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil
es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te
xt %2 Fpl ain
I believe it was upstream patched at the time but I won't
be surprised if something similar was reintroduced. It
happens when a Python internal integer type is converted to
a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s but
didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked
'I' format for the 'code' parameter because Python turns
0x800 into either a large positive number (PyLong or PyInt on
64-bit platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than
32bits in their unsigned long ioctl codes this will break and
need special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which converts a
Python integer to unsigned long. Please ignore the previous patch
and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6): ioctl
sign-extension ioctl 8004667e
Regards,
--
Mario S F Ferreira - DF - Brazil - I guess this is a signature.
feature, n: a documented bug | bug, n: an undocumented feature
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira wrote:
On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote:
Date: Wed, 23 Jun 2010 17:08:38 -0400
From: Jung-uk Kim j...@freebsd.org
To: freebsd-stable@FreeBSD.org
Cc: d...@delphij.net, Mario Sergio Fujikawa Ferreira
li...@freebsd.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING
ioctl sign-extension ioctl 8004667e
User-Agent: KMail/1.6.2
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira
wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension
ioctl 8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we
need to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in
kernel source code as a workaround.
By the way it seems to be a POSIX violation and we
didn't seem to really use so wide cmd, but I have not
yet verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python
/fil es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ
e=te xt %2 Fpl ain
I believe it was upstream patched at the time but I
won't be surprised if something similar was
reintroduced. It happens when a Python internal
integer type is converted to a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that
it would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s
but didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned
non-checked 'I' format for the 'code' parameter because
Python turns 0x800 into either a large positive number
(PyLong or PyInt on 64-bit platforms) or a negative number on
others (32-bit PyInt) whereas the system expects it to be a
32bit bit field value regardless of it being passed as an int
or unsigned long on various platforms. See the
termios.TIOCSWINSZ constant across platforms for an example
of thise.
If any of the 64bit platforms ever decide to use more
than 32bits in their unsigned long ioctl codes this will
break and need special casing based on the platform being
built on. */
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which
converts a Python integer to unsigned long. Please ignore the
previous patch and try the attached patch instead.
Unfortunately it didn't work.
1) Added patch to lang/python26
2) Recompiled lang/python26
3) cd /var/db/ports portupgrade -f python* py26* deluge*
Restarted deluge afterwards. The message is still there:
Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6):
ioctl sign-extension ioctl 8004667e
It may be a deeper problen, then. :-(
First of all, I cannot reproduce the problem because deluged dumps
core on my box and I gave it up. Just staring at the code, it seems
they rely on a bundled libtorrent for Python binding and the
libtorrent relies on Boost, in turn. Then, the actual non-blocking
socket implementation is done with Boost ASIO[1]. It is possible
that there are more complicated problems between these and the Python
binding. In fact, I can see a lot of these:
int name() const
{
return FIONBIO;
}
...
if (!ec command.name() == static_castint(FIONBIO))
...
socket_ops::ioctl(impl.socket_, command.name(), ...)
...
They are just assuming it is an int type, I guess.
Sigh, what a mess...
Jung-uk Kim
[1] Boost and its Python binding from ports seems
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
on 23/06/2010 05:58 Mario Sergio Fujikawa Ferreira said the following: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e This ioctl is FIONBIO. I believe that I saw another report about it on this list recently (~1 week ago). But it was for a different software. I've already recompiled all my python ports and dependencies. I am running up to date ports (today). $ uname -a FreeBSD exxodus.fedaykin.here 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #10: Thu Jun 17 12:28:13 BRT 2010 li...@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 These messages began this past week but I am not sure what might be to blame: latest ports or latest -STABLE. I guess it would be some port. The specific python port is deluge 1.3 RC1. It was running fine before this past week of changes. Does anyone have an idea what might be causing this? Do I have to be alarmed by this? The system is reliable despite these messages. This messages just warns about bad programming, but in this case the ioctl is processed correctly. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIk58AAoJEATO+BI/yjfBvaAIALLZMVxTN8xMfutobstHHEvc OMVlLcnNM4erbCpL7ThbwsyOBEc5gbNSGtK2jvE3Z82uIhM74NXoe5PwnMeN73Gy r8ShMVdfE5hhJC6HmjGx9sV/zf88dySAQ8n0uHUsIUUL0DnvEOvS7pIEs73Ozm3u Cm9+0k2re604pj3gyFOfaXnJBH8VwSk3VPtOBHGQJnpjNRoHDpT6hw0iRO4+O6UA DoGZHIXpBvM0Qb6unisNogDL1Vsg1A208JCPk96YJegH023HE1oE/jmhgqNwiA/V jZY4VcAJUG+Gpc86VGtZv+w3YIiObMTS4ohO+ktGxfxetPbF2QboIdRUnr28yyU= =Pwmz -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Long time ago, I had a similar problem with termios TIOCGWINSZ and we patched the port like this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain I believe it was upstream patched at the time but I won't be surprised if something similar was reintroduced. It happens when a Python internal integer type is converted to a native unsigned long. FYI... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/06/23 11:37, Jung-uk Kim wrote: On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Long time ago, I had a similar problem with termios TIOCGWINSZ and we patched the port like this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain I believe it was upstream patched at the time but I won't be surprised if something similar was reintroduced. It happens when a Python internal integer type is converted to a native unsigned long. Well, only *BSD have cmd a long value so it's likely that it would be reintroduced. I have checked the 4.4BSD archive and understood that our ioctl's cmd parameter was made long around 1991 or 1992s but didn't see what it actually buy us... Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIlVyAAoJEATO+BI/yjfBLgcIAKXIekJTGptB51L3XJaJL0q4 I+3nAqDcexDiTIAZ3ExDW47MNeh89fR5Iun2kgYlaOYtEEz8iFdJkrH2dgjkRGpt iBXcjuYw/rVINkvl03tovwIaDNmHjvD3NyvvTSOqmSsRnyR6Z7LACNqQr95nPzrF jJFS+AWT0QeytzhJFSAHXniR9paTsktnHTIN4XEdnYlzNIIhP8BoDgfJ3RqGJRk9 QcvZtait5JWHaGJFhGvN/j30lGsHPabt9zWqNVSHLJ9pSzfwAtW7Ihwso55/blYA JxkRUps2AfK9ZhvQ2B0eArVQLjA61HifVE1UNLrkh1KMeUPth4eIZvBZuWtJ7R8= =ZCD9 -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: On 2010/06/23 11:37, Jung-uk Kim wrote: On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Long time ago, I had a similar problem with termios TIOCGWINSZ and we patched the port like this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Att ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fpl ain I believe it was upstream patched at the time but I won't be surprised if something similar was reintroduced. It happens when a Python internal integer type is converted to a native unsigned long. Well, only *BSD have cmd a long value so it's likely that it would be reintroduced. Yes, that's what I mean. I have checked the 4.4BSD archive and understood that our ioctl's cmd parameter was made long around 1991 or 1992s but didn't see what it actually buy us... Like it or not, it is too late to revert. :-( Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following messages
a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it. Basically
this means that python (or some .so modules) passed an int or
unsigned int as parameter 'cmd', we need to change it to
unsigned long.
The warning itself should be harmless to my best of knowledge,
one can probably remove the printf in kernel source code as a
workaround.
By the way it seems to be a POSIX violation and we didn't seem
to really use so wide cmd, but I have not yet verified
everything myself.
Long time ago, I had a similar problem with termios TIOCGWINSZ
and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/A
tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2
Fpl ain
I believe it was upstream patched at the time but I won't be
surprised if something similar was reintroduced. It happens
when a Python internal integer type is converted to a native
unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our ioctl's
cmd parameter was made long around 1991 or 1992s but didn't see
what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x800
into either a large positive number (PyLong or PyInt on 64-bit
platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than 32bits
in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010/06/23 12:10, Jung-uk Kim wrote:
It is still a kludge and it won't be fixed. :-(
Another thought - what about just hiding the printf under #ifdef
DIAGNOSTIC... I don't really see any reason why we must print it out if
we truncate it every time...
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMIl2QAAoJEATO+BI/yjfBpz0IAM88YOx5CVoYRCEW8EwCaW+N
5Ugks9hCvbsJgU2yLxeg5hGal0wOHKONLxaq9pXvQFybgRT9SLmna2FJLTJ6XYTu
pjtjeby40mpwRTwU5rZgJ//aYgHW48kK9N/CoE63zKycYQbjLFGnZmXbel9itZzL
Xnpj9kc0zlpqtk6yZd4XA+m90VrIgnMKmxeP0A5OzuWJKUBmvciqSMYEBQ0pkP03
sSiN5QIzW/gRMgYSJEsTGz5+q10ZDf0NOecuhOujLphWLzWxkq6UOqRi3JXvFaqo
ajRDpGEG65r2IDd8qo4y50U0FGeHmysTFUPU3aAOzjb10LbNbmT6zX+3G1rSMFY=
=A2pe
-END PGP SIGNATURE-
Index: sys/kern/sys_generic.c
===
--- sys/kern/sys_generic.c (revision 209472)
+++ sys/kern/sys_generic.c (working copy)
@@ -628,9 +628,11 @@
caddr_t data;
if (uap-com 0x) {
+#ifdef DIAGNOSTIC
printf(
WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n,
td-td_proc-p_pid, td-td_name, uap-com);
+#endif
uap-com = 0x;
}
com = uap-com;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:16 pm, Xin LI wrote: On 2010/06/23 12:10, Jung-uk Kim wrote: It is still a kludge and it won't be fixed. :-( Another thought - what about just hiding the printf under #ifdef DIAGNOSTIC... I don't really see any reason why we must print it out if we truncate it every time... Yes, I agree. Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we need to
change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in kernel
source code as a workaround.
By the way it seems to be a POSIX violation and we didn't
seem to really use so wide cmd, but I have not yet verified
everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files
/A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text
%2 Fpl ain
I believe it was upstream patched at the time but I won't be
surprised if something similar was reintroduced. It happens
when a Python internal integer type is converted to a native
unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s but
didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x800
into either a large positive number (PyLong or PyInt on 64-bit
platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than
32bits in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and test.
Note I am not a Python guy, so please don't shoot me. ;-)
Thanks,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.0 -0400
+++ Modules/fcntlmodule.c 2010-06-23 15:27:42.0 -0400
@@ -110,7 +110,12 @@
in their unsigned long ioctl codes this will break and need
special casing based on the platform being built on.
*/
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__OpenBSD__)
+ unsigned long code;
+#else
unsigned int code;
+#endif
int arg;
int ret;
char *str;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
On 2010/06/23 11:37, Jung-uk Kim wrote:
On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
Hi,
On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
Hi,
I am getting more than 4 thousand of the following
messages a day:
WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
8004667e
[...]
I think we may need to check the code and patch it.
Basically this means that python (or some .so modules)
passed an int or unsigned int as parameter 'cmd', we need
to change it to unsigned long.
The warning itself should be harmless to my best of
knowledge, one can probably remove the printf in kernel
source code as a workaround.
By the way it seems to be a POSIX violation and we didn't
seem to really use so wide cmd, but I have not yet
verified everything myself.
Long time ago, I had a similar problem with termios
TIOCGWINSZ and we patched the port like this:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil
es /A tt
ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te
xt %2 Fpl ain
I believe it was upstream patched at the time but I won't
be surprised if something similar was reintroduced. It
happens when a Python internal integer type is converted to
a native unsigned long.
Well, only *BSD have cmd a long value so it's likely that it
would be reintroduced.
Yes, that's what I mean.
I have checked the 4.4BSD archive and understood that our
ioctl's cmd parameter was made long around 1991 or 1992s but
didn't see what it actually buy us...
Like it or not, it is too late to revert. :-(
From Python 2.6.5:
static PyObject *
fcntl_ioctl(PyObject *self, PyObject *args)
{
#define IOCTL_BUFSZ 1024
int fd;
/* In PyArg_ParseTuple below, we use the unsigned non-checked
'I' format for the 'code' parameter because Python turns
0x800 into either a large positive number (PyLong or PyInt on
64-bit platforms) or a negative number on others (32-bit PyInt)
whereas the system expects it to be a 32bit bit field value
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
If any of the 64bit platforms ever decide to use more than
32bits in their unsigned long ioctl codes this will break and
need special casing based on the platform being built on.
*/
unsigned int code;
...
It is still a kludge and it won't be fixed. :-(
Please drop the attached patch in ports/lang/python26/files and
test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which converts a
Python integer to unsigned long. Please ignore the previous patch
and try the attached patch instead.
Cheers,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.0 -0400
+++ Modules/fcntlmodule.c 2010-06-23 16:56:10.0 -0400
@@ -97,6 +97,13 @@
{
#define IOCTL_BUFSZ 1024
int fd;
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+defined(__OpenBSD__)
+#define IOCTL_ULONG 1
+#endif
+#ifdef IOCTL_ULONG
+ unsigned long code;
+#else
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x800
into either a large positive number (PyLong or PyInt on 64-bit
@@ -105,12 +112,9 @@
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
-
- If any of the 64bit platforms ever decide to use more than 32bits
- in their unsigned long ioctl codes this will break and need
- special casing based on the platform being built on.
*/
unsigned int code;
+#endif
int arg;
int ret;
char *str;
@@ -118,7 +122,11 @@
int mutate_arg = 1;
char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, Okw#|i:ioctl,
+#else
if (PyArg_ParseTuple(args, OIw#|i:ioctl,
+#endif
conv_descriptor, fd, code,
str, len, mutate_arg)) {
char *arg;
@@ -169,7 +177,11 @@
}
PyErr_Clear();
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, Oks#:ioctl,
+#else
if (PyArg_ParseTuple(args, OIs#:ioctl,
+#endif
conv_descriptor, fd, code, str,
