[issue15898] OSX TTY bug

Ronald Oussoren added the comment: Closing this issue, because this is a platform bug. The reproducer in msg170147 works reliably for me on macOS 10.15 with Python 3.9, the system bug may have been fixed in the meantime. -- components: +macOS resolution: not a bug -> third party sta

[issue15898] OSX TTY bug

Ronald Oussoren added the comment: This is IMHO not a bug in Python, the problem can been seen when you rewrite the code in msg170261 in C, see the code below. An observation with the C code below: Both moving ``close(slave)`` to above the sleep or removing that close entirely fixes the prob

[issue15898] OSX TTY bug

Changes by Ronald Oussoren : -- nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue15898] OSX TTY bug

Martin v. Löwis added the comment: Am 11.09.2012 09:11, schrieb Andrew Moffat: > I'm not sure I follow the problem exactly. So you're saying that the > failing version uses _cancel sys calls, and that __pthread_testcancel > may result in EINTR. But that this is not happening in the trace, > and

[issue15898] OSX TTY bug

Andrew Moffat added the comment: Sorry about that, I refactored out the string at the last minute and typed "testing123" instead of the original "testing" from the trace. I'm not sure I follow the problem exactly. So you're saying that the failing version uses _cancel sys calls, and that __pt

[issue15898] OSX TTY bug

Martin v. Löwis added the comment: To me, this still looks like an OS bug. The difference between 2.7 and 3.2 seems to be that 3.2 will call the _nocancel syscalls, which I guess results from using a different version of the C library, or OSX deployment target, or something. However, the syste

[issue15898] OSX TTY bug

Andrew Moffat added the comment: Below I attached a script that reproduces the behavior of an assertion error on a specific fork condition for a process with a pty. Here are the results Xubuntu x64: Python 2.7, parent_close_slave_before_child_write = False: WORKS Python 2.7, parent_close

[issue15898] OSX TTY bug

Andrew Moffat added the comment: @Ned, Ok, give me a little time to work up those suggestions. On my machine, the previous script prints "testing" consistently on 2.7, "" consistently on 3.2. I guess this is the behavior that is unexpected...it should print the same thing for both versions.

[issue15898] OSX TTY bug

Martin v. Löwis added the comment: If you want to analyse this further, please provide "dtruss -f" output of the script. Most likely, this is a glitch in the operating system, but not a bug in Python. Unless you can provide more details, or a patch, we are likely to close this issue as "works

[issue15898] OSX TTY bug

Ned Deily added the comment: Sorry, all I can tell you is that, for me, your test produces an empty string as output with either Python 2.7 or 3.3 and, if I remove the time.sleep() call or remove the os.close(slave), "testing" or b"testing" is output. I'm not sure what you believe the problem

[issue15898] OSX TTY bug

Andrew Moffat added the comment: If I move tcsetattr into the parent, the race condition still exists. If I move it into the child, before the write(), it works. My environment is OSX 10.7.2 inside of Virtualbox (maybe this is the problem?) I've shuffled some code around, and found case that

[issue15898] OSX TTY bug

Ned Deily added the comment: I have not been able to reproduce the behavior you report using various Pythons on OS X 10.8 or on OS X 10.5. Can you give more specifics on the environment that fails for you? I certainly don't claim to have any experience with these tty/pty modules or with the

[issue15898] OSX TTY bug

New submission from Andrew Moffat: I'm getting some kind of race condition on OSX when trying to read the output from a pseudoterminal of a forked process. This race conditional only occurs if I run tty.tcsetattr on the master side of the pty, regardless of if I actually change the mode or no