New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
corrupted contents of stdout result from subprocess call under a trace #59210
Comments
This code dumps a lot of internal source code info when executed with trace as: python -m trace --trace file2.py ---[file2.py] def ret():
output = subprocess.check_output(['hg', 'id', '-nib'])
print( output )
print( output )
print( output.strip() )
print( output.strip().split() )
ret() Normally, the last line of the output is: But during trace call it is: |
The behavior repeats with PyPy 1.8.0, and doesn't repeat with Python 3. |
Python2 has a pure python implementation of subprocess, with separate calls to fork() and exec(); so the output of the subprocess contains the trace of the forked Python interpreter, until the exec() system call. Yes, Python3 is better :) |
OMG. =) Is it possible to fix it somehow? Postpone output collection until the very exec() call? Or provide a different stream for collecting output? |
It's not possible to delay output collection: output starts being collected just after the call os.dup2(cp2write, 1) and before exec(), we need to os.close it. The trace module will already have emitted some lines. Process output by definition goes to the C stdout, but you could redirect sys.stdout (the Python one, used by print) to something else, like a StringIO so that trace.py does not pollute the subprocess output. In 3.2, suprocess.py states that the pure Python implementation (the one use in 2.7) is not thread safe. We could add that it's not reentrant or trace-friendly as well... this is not surprising IMO. |
Is it possible to pause trace and resume after the exec call? Between some missing instructions from subprocess internals and traceability of the Python programs I'd choose the latter. It can be even more actual for people tracing program execution in the process of porting to Python 3. |
Sure, just save/restore the trace function around your calls to subprocess. |
The fix for saving/restoring trace function belong to subprocess module. Python2 only issue will be actual when you have to port Python2 only app where it works ok to the Python3 where it doesn't work even if it executes successfully. |
Sorry, what does not work in Python3? |
The trace module helps to gather program flow statistics and see the differences in patterns for large systems when program evolves. In particular, components ported to Python 3 should still behave the same way on Python 2. Right now the behavior under the trace is broken. |
This use case is actual for various kind of asynchronous operations. |
I can't repeat this on Windows. Looks like it is a Linux issue, because of forks. |
So, does this page report an issue with Python2, or Python3? |
I can not repeat this neither on Python 2.7 nor on Python 3 on Windows Vista. Need to run this on a Linux system to confirm. |
Python 3 is not affected. Python 2.7, Linux only. |
So the issue can be closed:
import sys
import subprocess32 as subprocess
sys.modules['subprocess'] = subprocess |
And how to find all such issues for Python 2 that people need to be aware of in this tracker? |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: