From: Elliot M. <ma...@ad...> - 2010-05-06 22:58:43
|
Hello, Just wondering if anyone may have come across an issue similar to a weird one I've just come across... I am using subprocess.Popen in Python 2.5.1 on gumstix Verdex Pro with Linux 2.6.21 kernel. It seems that on occasion - maybe 1 in 3 or 1 in 4 attempts - where I create subprocess.Popen to launch a file without a shell, the code will lock and require an external kill to remove the process. This same code works fine on hardware other than gumstix. Note that this crashes _before_ the Popen.communicate() method is called, it locks just when instantiating the process. The locking seems to be random. I have traced the issue as far as os.dup2 in the Python source for subprocess.py, which is not returning. It locks here: <snippet from subprocess.py, just after the child fork> if self.pid == 0: # Child try: # Close parent's pipe ends if p2cwrite is not None: os.close(p2cwrite) if c2pread is not None: os.close(c2pread) if errread is not None: os.close(errread) os.close(errpipe_read) <snip> if c2pwrite is not None: os.dup2(c2pwrite, 1) # WE CRASH HERE - DEADLOCK If I am correct, and I am still digging, os.dup2 maps to dup2.c in the Python source. This function is not returning in Python. Dup2 is a C-level function which is largely kernel dependent. I have seen reports of dup2 hanging on mingw targets with specific kernels, and I'm wondering if the same is true here for VerdexPro. Any tips before I get stuck into this one? Regards, Elliot. |