You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Linux x86_64 (glibc)
swift-2.2-SNAPSHOT-2015-12-31-a
Additional Detail from JIRA
Votes
0
Component/s
Foundation
Labels
Bug
Assignee
Eugene Gubin (JIRA)
Priority
Medium
md5: e1a9699af115cfcb14b4871015c130ae
Issue Description:
This is a bug in swift-corelibs-foundation; it's a regression new in the dec-31 snapshot. You cannot run buildbot_linux without a TTY attached (for example, in a Docker container).
The root cause is the implementation of NSUserName, which is exercised in a test suite and will crash without a TTY.
The actual root cause is that getlogin(_r) does not work without a TTY due to a glibc bug.
According to the the manpage, getlogin_r call can fail if:
Standard input didn't refer to a terminal. (See BUGS.)
It goes on to explain:
Unfortunately, it is often rather easy to fool getlogin(). Sometimes it does not work at all, because some program messed up the utmp file. Often, it gives only the first 8 characters of the login name. The user currently logged in on the controlling terminal of our program need not be the user who started it. Avoid getlogin() for security-related purposes.
Note that glibc does not follow the POSIX specification and uses stdin instead of /dev/tty. A bug. (Other recent systems, like SunOS 5.8 and HP-UX 11.11 and FreeBSD 4.8 all return the login name also when stdin is redirected.)
This glibc bug occurs in real-world scenarios:
1. This call is exercised in a test that runs under buildbot_linux
2. I build buildbot_linux inside a Docker container
3. Docker containers have no attached tty during a build
4. The swift-2.2-SNAPSHOT-2015-12-31-a can no longer be built for Docker.
The bug can be reproduced (although it takes awhile) on any system with Docker installed by creating a file called 'Dockerfile' with the following contents and then running "docker build ."
FROMdebian:latestENVSWIFT_TAG="swift-2.2-SNAPSHOT-2015-12-31-a"RUNTIME_PACKAGES="clang libedit2 libpython2.7 libxml2 libicu52"BUILDTIME_PACKAGES="git ca-certificates python ninja-build cmake uuid-dev libbsd-dev libicu-dev pkg-config libedit-dev file libxml2-dev python-dev libncurses5-dev libsqlite3-dev libreadline6-dev rsync"RUN \
# Createadirectorytoworkin \
mkdirswift-dev && \
cdswift-dev && \
# Installtheruntimeandbuild-timedependencies \
apt-getupdate && \
apt-getinstall$RUNTIME_PACKAGES$BUILDTIME_PACKAGES -y --no-install-recommends && \
\
gitclonehttps://github.com/apple/swift.git && \cdswift && \
# submodules? Wherewe're going, we don'tneedsubmodules! \
./utils/update-checkout --clone && \
\
# Thesillyupdate-checkoutscriptdoesnotunderstandmatchingtheswiftcheckoutref \
# Inpracticewhatyou're supposed to do (I think! It'snotdocumented!) ischeckoutthesamesnapshottag \
# Notallthefoldershavethem (wheredosomeofthemcomefrom??) butwe'll just try them all \ find ../ -maxdepth 1 -type d -exec bash -c '(cd {} && echocheckingoutin `pwd` && gitcheckout$SWIFT_TAG)' \; && \
\
# And now we build, like a good little linuxen. \
# I believe this is what the linux build script does. In practice, this builds a system into /tmp/install and then tars it up. \
./utils/build-script --preset=buildbot_linux install_destdir="/tmp/install" installable_package="/tmp/swift.tar.gz" && \
\
# Install our tarball to /usr/local \
tar xf /tmp/swift.tar.gz -C /usr/local --strip-components 1 && \
\
# Clean up \
cd / && \
rm -rf /tmp/swift.tar.gz /swift-dev && \
apt-get remove --purge -y $BUILDTIME_PACKAGES && \
apt-get autoremove --purge -y && \
apt-get clean -y && \
apt-get autoclean -y && \
rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
ENTRYPOINT ["bash"]
This produces a "fatalError - could not get login name" with errno ENOTTY.
It's not immediately clear how to fix this so I'm pinging the implementor of NSUserName.
The text was updated successfully, but these errors were encountered:
Hmm "Jeff" might not be a good default return value here; perhaps "" or "unknown" etc might be a bit more appropriate and less confusing. We may want to also consider reducing the unit test scope for non TTY enabled sessions and skip certain tests when that is the case
Environment
Linux x86_64 (glibc)
swift-2.2-SNAPSHOT-2015-12-31-a
Additional Detail from JIRA
md5: e1a9699af115cfcb14b4871015c130ae
Issue Description:
This is a bug in swift-corelibs-foundation; it's a regression new in the dec-31 snapshot. You cannot run buildbot_linux without a TTY attached (for example, in a Docker container).
The root cause is the implementation of NSUserName, which is exercised in a test suite and will crash without a TTY.
The actual root cause is that getlogin(_r) does not work without a TTY due to a glibc bug.
According to the the manpage, getlogin_r call can fail if:
It goes on to explain:
This glibc bug occurs in real-world scenarios:
1. This call is exercised in a test that runs under buildbot_linux
2. I build buildbot_linux inside a Docker container
3. Docker containers have no attached tty during a build
4. The swift-2.2-SNAPSHOT-2015-12-31-a can no longer be built for Docker.
The bug can be reproduced (although it takes awhile) on any system with Docker installed by creating a file called 'Dockerfile' with the following contents and then running "docker build ."
This produces a "fatalError - could not get login name" with errno ENOTTY.
It's not immediately clear how to fix this so I'm pinging the implementor of NSUserName.
The text was updated successfully, but these errors were encountered: