[PATCH] Fix usage of posix_spawn_file_actions_addopen

[Rafael Espíndola]

How about creating the std::string in the caller? would the attached
patch (with comments about what is going on) work?

On 26 July 2013 10:25, Hal Finkel <hfinkel at anl.gov> wrote:
> Hello,
>
> The Execute function in Unix/Program.inc uses posix_spawn, when available (and when no memory limit is requested), to execute child programs. When file descriptor redirection is specified, posix_spawn_file_actions_addopen is used to add an open file action to the posix_spawn request. Unfortunately, the argument to posix_spawn_file_actions_addopen is obtained by calling File.c_str(), and so the lifetime of the provided pointer is limited. On systems using glibc, this does not work. The implementation assumes that the lifetime of the provided pointer will not end prior to the call to posix_spawn itself(*).
>
> This problem was causing bugpoint to (nondeterministically) fail to execute gcc on some of my systems.
>
> I've attached a patch which extends the lifetime of the strings provided to posix_spawn_file_actions_addopen, allowing this to work correctly with glibc. The standard does not seem to specify one way or the other what string lifetime is expected. Alternatively, we could consider glibc broken in this area, and avoid using posix_spawn with glibc.
>
> Please review.
>
> Thanks again,
> Hal
>
> (*) You can see this by looking at the source, see:
> http://fossies.org/dox/glibc-2.17/spawn__faction__addopen_8c_source.html#l00027
>
> As a quick example of something else, here's a different implementation that does make a copy of the provided string:
> https://github.com/evanphx/ulysses-libc/blob/master/src/process/posix_spawn_file_actions_addopen.c
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 2480 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130726/72bb2557/attachment.obj>