[Lldb-commits] [PATCH] D13836: Fix write-after-close of file descriptor in ScriptInterpreterPython

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Fri Oct 16 16:43:52 PDT 2015

zturner created this revision.
zturner added reviewers: clayborg, granata.enrico.
zturner added a subscriber: lldb-commits.

When we acquire the GIL with `Locker`, we save off the current stdio handles, redirect them, and when we release the GIL we put the old handles back.  This triggers a potential write-after-close, as follows:

In `ScriptInterpreterPython::ExecuteOneLine`, we set up a pipe, lock the gil, kick off a thread to do some work, then close the write end of the pipe.  However, the write end of the pipe in this case is the same thing that we set Python's stdout and stderr handles to, and we haven't yet restored them until `ExecuteOneLine` ends, due to the scope in which the RAII object is declared.

This has always been fine, but only as a coincidence.  In Python 3 it seems that when you set `stderr` to a new file, it writes to the *original* file first (probably to flush it).  In the case of `ExecuteOneLine`, that file descriptor has been intentionally closed by caller as a means to break the pipe and join the other thread it was communicating with, so we get an error.

The fix here is simple: Just acquire the GIL in a tighter scope so that stdin, stdout, and stderr are reset to their original values before trying to join the read thread.

It doesn't *seem* like we need to hold the GIL any longer than this since no Python calls are happening outside of the new smaller scope I've introduced, but let me know if you can think of anything wrong with this.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D13836.37655.patch
Type: text/x-patch
Size: 7385 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20151016/20641b1c/attachment-0001.bin>

More information about the lldb-commits mailing list