Issue821948
Created on 2003-10-11 22:08 by albertogli, last changed 2009-02-13 05:57 by loewis. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| fcntl.tar.bz2 | albertogli, 2003-10-14 03:31 | fcntlmodule preprocessor and assembler output | ||
| Messages (7) | |||
|---|---|---|---|
| msg18607 - (view) | Author: Deleted User albertogli (albertogli) | Date: 2003-10-11 22:08 | |
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
|
|||
| msg18608 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2003-10-12 17:41 | |
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?
|
|||
| msg18609 - (view) | Author: Deleted User albertogli (albertogli) | Date: 2003-10-13 17:06 | |
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.
|
|||
| msg18610 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2003-10-13 21:33 | |
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? |
|||
| msg18611 - (view) | Author: Deleted User albertogli (albertogli) | Date: 2003-10-14 03:31 | |
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. |
|||
| msg18612 - (view) | Author: Martin v. Löwis (loewis) * ![]() |
Date: 2003-10-14 17:56 | |
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? |
|||
| msg81878 - (view) | Author: Daniel Diniz (ajaksu2) | Date: 2009-02-13 04:41 | |
Anyone interested in keeping this one open? |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2009-02-13 05:57:07 | loewis | set | status: open -> closed resolution: works for me |
| 2009-02-13 04:41:09 | ajaksu2 | set | priority: normal -> low nosy: + ajaksu2 type: behavior messages: + msg81878 stage: test needed |
| 2003-10-11 22:08:58 | albertogli | create | |
