Skip to content
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

[SR-566] NSTask should forward a valid environment #815

Closed
drewcrawford opened this issue Jan 17, 2016 · 10 comments
Closed

[SR-566] NSTask should forward a valid environment #815

drewcrawford opened this issue Jan 17, 2016 · 10 comments

Comments

@drewcrawford
Copy link

Previous ID SR-566
Radar None
Original Reporter @drewcrawford
Type Bug
Status Resolved
Resolution Done

Attachment: Download

Environment

I've provided a portable Docker image to reproduce this issue.
However the affected config is Linux/64 running swift-2.2-SNAPSHOT-2016-01-11-a

Additional Detail from JIRA
Votes 0
Component/s Foundation, llbuild
Labels Bug
Assignee @phausler
Priority Medium

md5: 8d5ae1975f299ee92516cc443b1a116f

Issue Description:

....this is an odd bug.

swift-build-tool returns error code 127 when it happens to be invoked via NSTask.

An identical invocation that isn't via NSTask works fine. ...I am as puzzled as you.

To assist with reproducing this issue, I've created a portable Docker image that exactly matches my environment. Reproduction steps:

1. Extract the files to some directory
2. docker build .

Expected results: Container builds
Actual results: Docker container fails to build

Essentially:

1. The docker container tries to invoke launch.swift
2. launch.swift creates an NSTask that calls swift-build-tool
3. swift-build-tool returns error code 127 to launch.swift
4. launch.swift hits fatalError codepath

If you instead invoke swift-build-tool in exactly the same way without NSTask, everything's fine:

RUN swift launch.swift #doesn't work
# RUN swift-build-tool -f .atllbuild/llbuild.yaml #works fine

Theories:

1. Maybe corelibs-Foundation is doing something strange?
2. could swift-build-tool be expecting a tty / stdin / stdout?

@drewcrawford
Copy link
Author

cc: @ddunbar

@ddunbar
Copy link
Member

ddunbar commented Jan 18, 2016

I haven't tried the docker test, but I tried this locally with your launch.swift and it works.

I suspect the problem you are hitting is related to the opening of the database. Will swift-build-tool have permissions to open .atllbuild/build.db?

@ddunbar
Copy link
Member

ddunbar commented Jan 18, 2016

Oh, actually that wouldn't explain why the same swift-build-tool invocation works inside the container. I verified I can repro w/ your docker container, investigating...

@ddunbar
Copy link
Member

ddunbar commented Jan 18, 2016

The problem is in your launch.swift, it has the wrong path to swift-build-tool, which is at /usr/local/bin, not /usr/bin.

If you fix that then you will get further (link still fails, probably because container doesn't have /usr/bin/clang++ I would guess?)

@drewcrawford
Copy link
Author

Updating path in reproduction case to /usr/local/bin.

clang++ is installed; and can link programs, otherwise this would never work. In reality this always works, except when NSTask spawned the process.

I don't know why the linker fails in this situation; that is the bug.

I have also tested if we can do NSTask->shell->sbt->linker, and the answer appears to be that any use of NSTask will break the linker. I have no theories for why that is so; the obvious candidates like environment variables (even if NSTask tries to break them) would be restored by the shell.

I am currently working around successfully with the POSIX "system(3)" call which is not affected by this issue.

@ddunbar
Copy link
Member

ddunbar commented Jan 18, 2016

In this case the problem is simply that NSTask isn't preserving the environment, so PATH isn't propagated to subprocess by NSTask.

Going NSTask -> shell works for me, but you have to remember to use "sh -l" to cause the environment to be reinitialized.

/cc @parkera

@parkera
Copy link
Member

parkera commented Jan 19, 2016

Thanks for tracking that down. Philippe, maybe you can take a look at this one?

@phausler
Copy link
Member

Hmm looks like we don't do anything with the env but pass nil. Seems like an easy fix.

@phausler
Copy link
Member

I pushed a change that should resolve this: apple/swift-corelibs-foundation@b3637a7

It would be good if this could be verified that the environment passing is correct. I did not get a chance yet to try it out with docker.

@phausler
Copy link
Member

Needs verification

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants