fcntl() not working on sparc/linux (python 2.2.3)

[albertogli]

BPO	821948
Nosy	@loewis, @devdanzin
Files	fcntl.tar.bz2: fcntlmodule preprocessor and assembler output

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-02-13.05:57:07.674>
created_at = <Date 2003-10-11.22:08:58.000>
labels = ['extension-modules', 'type-bug']
title = 'fcntl() not working on sparc/linux (python 2.2.3)'
updated_at = <Date 2009-02-13.05:57:07.657>
user = 'https://bugs.python.org/albertogli'

bugs.python.org fields:

activity = <Date 2009-02-13.05:57:07.657>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2009-02-13.05:57:07.674>
closer = 'loewis'
components = ['Extension Modules']
creation = <Date 2003-10-11.22:08:58.000>
creator = 'albertogli'
dependencies = []
files = ['1070']
hgrepos = []
issue_num = 821948
keywords = []
message_count = 7.0
messages = ['18607', '18608', '18609', '18610', '18611', '18612', '81878']
nosy_count = 3.0
nosy_names = ['loewis', 'albertogli', 'ajaksu2']
pr_nums = []
priority = 'low'
resolution = 'works for me'
stage = 'test needed'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue821948'
versions = []

[albertogli]

In sparc, fcntl.fcntl() is not working properly under
Python 2.2.3;
a simple strace of:

import fcntl, sys
fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL,
os.O_NONBLOCK)

will reveal that on sparc there's no fcntl() syscall
done, while
under x86 it works as expected (ie. the syscall is there).

I have not tested yet with Python 2.3 but I'll let you
know when I do.

Thanks,
Alberto

[loewis]

Logged In: YES
user_id=21627

I cannot reproduce this. My binary of 2.2.1 does

read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84
read(3, "", 8192) = 0
llseek(3, 0, SEEK_CUR) = 0
close(3) = 0
fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3),
...}) = 0
fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0
sigaction(SIGINT, {SIG_DFL}, NULL) = 0

Can you attach your strace output? Can you also try truss?
What Solaris version and patches, what compiler?

[albertogli]

Logged In: YES
user_id=44390

I'm sorry I didn't specify earlier, this is a box running Linux
(gentoo distribution) with:

Linux Kernel 2.4.20
glibc 2.2.5
gcc 2.95.3
python 2.2.3

The fragment of the strace output is the following, it's
between I
press the final '\n' and the response '0\n' appears:

write(1, "\n", 1) = 1
rt_sigprocmask(SIG_BLOCK, [INT], [32], 8) = 0
ioctl(0, 0x8024540a, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [32], NULL, 8) = 0
rt_sigaction(SIGINT, {0x700486f8, [], 0}, {0x700486f8, [],
0}, 0x701431c8, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGTTOU, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGTTIN, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGWINCH, {SIG_DFL}, {0x700486f8, [], 0},
0x701431c8, 8) = 0
rt_sigaction(SIGINT, NULL, {0x700486f8, [], 0}, 0, 8) = 0
rt_sigaction(SIGINT, {0x700486f8, [], 0}, NULL, 0x701431c8,
8) = 0
nfssvc(0) = 0
write(1, "0\n", 2) = 2

On x86 the fcntl64() syscall happens right before the write().

I don't think the bug is present in earlier versions of
Python because I
remember this used to work fine before the upgrade, however
I can't
pinpoint the exact release this started to show up.

Let me know if you need additional info or want me to do
some tests.

[loewis]

Logged In: YES
user_id=21627

It would be good if you could attach preprocessor output and
assembler code (both obtained through --save-temps) for
fcntlmodule.c. If this is too large to attach you might need
to compress it, if it is then still too large, you would
need to strip all but fcntl_fcntl.

Also, are you using a 32-bit or a 64-bit compiler?

[albertogli]

Logged In: YES
user_id=44390

I'm attaching both, tar.bz2 compressed, about 45k, without any
stripping whatsoever.

Linux on Sparc userspace is always 32 bit, but the kernel
is 64 bit on sparc64 and 32 bit on sparc32.

In this case, userspace is 32 bit and kernel 64 bit.

[loewis]

Logged In: YES
user_id=21627

I can't see anything strange in the assembler code. Also,
from looking both at the source code, and the assembler
code, there is absolutely no code path which could cause
fcntl *not* to be called, except if an exception is raised.

Can you run this in a debugger, setting a break-point on
fcntl_fcntl, and see how it steps through the code?

[devdanzin]

Anyone interested in keeping this one open?