ASan runtime does not come first


(Joe Bell) #1

Well, I thought the REPL issues had all been put to rest, but now I am
seeing this on Ubuntu 14.04 (15.10 I do not see it):

➜ package-swift-3.0 git:(swift-3.0) ✗ ./install/usr/bin/swift
==18928==ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it with
LD_PRELOAD.

This is with the "master" branches that build Swift 3.0, hashes:

$ swift swiftrevs.swift
swift:95e3be665d
llvm:752e1430fc
clang:1e6cba3ce3
lldb:a38bed5855
compiler-rt:a897309947
cmark:5af77f3c1d
llbuild:ea9fd78a4a
swiftpm:22954afe9f
swift-corelibs-xctest:efdde9849c
swift-corelibs-foundation:d2dc9f3cf9
swift-integration-tests:98f6c6d992
swift-corelibs-libdispatch:65330e06d9

Is anyone else building the world on Ubuntu 14.04 that can verify this?
Regards,
Joe

···

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit


(Ryan Lovelett) #2

Well, I thought the REPL issues had all been put to rest, but now I am
seeing this on Ubuntu 14.04 (15.10 I do not see it):

➜ package-swift-3.0 git:(swift-3.0) ✗ ./install/usr/bin/swift
==18928==ASan runtime does not come first in initial library list; you
==should either link runtime to your application or manually preload
==it with LD_PRELOAD.

This is with the "master" branches that build Swift 3.0, hashes:

$ swift swiftrevs.swift
swift:95e3be665d
llvm:752e1430fc
clang:1e6cba3ce3
lldb:a38bed5855
compiler-rt:a897309947
cmark:5af77f3c1d
llbuild:ea9fd78a4a
swiftpm:22954afe9f
swift-corelibs-xctest:efdde9849c
swift-corelibs-foundation:d2dc9f3cf9
swift-integration-tests:98f6c6d992
swift-corelibs-libdispatch:65330e06d9

Is anyone else building the world on Ubuntu 14.04 that can
verify this?

I have seen this behavior many times in many scenarios. Almost always it
has to do with a build parameter.

Recently I have noticed that compiling with the "compiler-rt" project
seems to cause this issue frequently. I do not understand what "compiler-
rt" is, or what its value to Swift is, so I just omit it from my builds.
It maybe worth while to do the same and rebuild and see if it goes away.

I would think that if "compiler-rt" is the source of the issues then
something likely needs to be submitted to bugs.swift.org.

Another thing to check is if your packaging Swift (dep, rpm, pacman,
etc...) that you are do not strip symbols from binaries and libraries as
part of packaging.

···

On Sun, Apr 24, 2016, at 05:44 PM, Joseph Bell via swift-dev wrote:

Regards,
Joe

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
_________________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Joe Bell) #3

I've just noticed (thanks to you Ryan) that compiler-rt is indeed checked
out and included in the 14.04 build but not the 15.10. I'm going to
rebuild from the ground up on 15.10 to see if it grabs compiler-rt and
reproduces, as this is being checked out by the ci.swift.org CI server.

This error occurs before any downstream packaging (deb) and is failing the
build itself (on the test REPL, it can't even load). Will report back in a
bit.

Joe

···

On Mon, Apr 25, 2016 at 7:52 AM, Ryan Lovelett <swift-dev@ryan.lovelett.me> wrote:

On Sun, Apr 24, 2016, at 05:44 PM, Joseph Bell via swift-dev wrote:

Well, I thought the REPL issues had all been put to rest, but now I am
seeing this on Ubuntu 14.04 (15.10 I do not see it):

➜ package-swift-3.0 git:(swift-3.0) ✗ ./install/usr/bin/swift
==18928==ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it with
LD_PRELOAD.

This is with the "master" branches that build Swift 3.0, hashes:

$ swift swiftrevs.swift
swift:95e3be665d
llvm:752e1430fc
clang:1e6cba3ce3
lldb:a38bed5855
compiler-rt:a897309947
cmark:5af77f3c1d
llbuild:ea9fd78a4a
swiftpm:22954afe9f
swift-corelibs-xctest:efdde9849c
swift-corelibs-foundation:d2dc9f3cf9
swift-integration-tests:98f6c6d992
swift-corelibs-libdispatch:65330e06d9

Is anyone else building the world on Ubuntu 14.04 that can verify this?

I have seen this behavior many times in many scenarios. Almost always it
has to do with a build parameter.

Recently I have noticed that compiling with the "compiler-rt" project
seems to cause this issue frequently. I do not understand what
"compiler-rt" is, or what its value to Swift is, so I just omit it from my
builds. It maybe worth while to do the same and rebuild and see if it goes
away.

I would think that if "compiler-rt" is the source of the issues then
something likely needs to be submitted to bugs.swift.org.

Another thing to check is if your packaging Swift (dep, rpm, pacman,
etc...) that you are do not strip symbols from binaries and libraries as
part of packaging.

Regards,
Joe

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
*_______________________________________________*
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit


(Joe Bell) #4

What I've found out so far is that the tree built in the 'install'
directory (./install/usr) is not suitable to live side-by-side with /usr/
on the host machine. My original approach (documented on
http://dev.iachieved.it/iachievedit/) was to ball everything up into a .deb
package that installed as an overlay to /usr/, this was just to make it
simple to get started.

Now with swift-2.2 and swift-3.0 and the possibility one might want to use
both (python2.7, python3), I'm going to change over to placing in
/opt/swift/VERSION and provide some alternatives mechanism, OR, use the
approach that python2.7, 3, etc. use where there is a /usr/bin/python2.7/,
/usr/lib/python2.7/, etc. and /usr/bin/python links back there.

tl;dr: I don't know what occurs exactly but the equivalent of rsync -a
./install/usr/ /usr/ (overlay) causes mayhem for starting the REPL.

···

On Mon, Apr 25, 2016 at 8:02 AM, Joseph Bell <joe@iachieved.it> wrote:

I've just noticed (thanks to you Ryan) that compiler-rt is indeed checked
out and included in the 14.04 build but not the 15.10. I'm going to
rebuild from the ground up on 15.10 to see if it grabs compiler-rt and
reproduces, as this is being checked out by the ci.swift.org CI server.

This error occurs before any downstream packaging (deb) and is failing the
build itself (on the test REPL, it can't even load). Will report back in a
bit.

Joe

On Mon, Apr 25, 2016 at 7:52 AM, Ryan Lovelett <swift-dev@ryan.lovelett.me > > wrote:

On Sun, Apr 24, 2016, at 05:44 PM, Joseph Bell via swift-dev wrote:

Well, I thought the REPL issues had all been put to rest, but now I am
seeing this on Ubuntu 14.04 (15.10 I do not see it):

➜ package-swift-3.0 git:(swift-3.0) ✗ ./install/usr/bin/swift
==18928==ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it with
LD_PRELOAD.

This is with the "master" branches that build Swift 3.0, hashes:

$ swift swiftrevs.swift
swift:95e3be665d
llvm:752e1430fc
clang:1e6cba3ce3
lldb:a38bed5855
compiler-rt:a897309947
cmark:5af77f3c1d
llbuild:ea9fd78a4a
swiftpm:22954afe9f
swift-corelibs-xctest:efdde9849c
swift-corelibs-foundation:d2dc9f3cf9
swift-integration-tests:98f6c6d992
swift-corelibs-libdispatch:65330e06d9

Is anyone else building the world on Ubuntu 14.04 that can verify this?

I have seen this behavior many times in many scenarios. Almost always it
has to do with a build parameter.

Recently I have noticed that compiling with the "compiler-rt" project
seems to cause this issue frequently. I do not understand what
"compiler-rt" is, or what its value to Swift is, so I just omit it from my
builds. It maybe worth while to do the same and rebuild and see if it goes
away.

I would think that if "compiler-rt" is the source of the issues then
something likely needs to be submitted to bugs.swift.org.

Another thing to check is if your packaging Swift (dep, rpm, pacman,
etc...) that you are do not strip symbols from binaries and libraries as
part of packaging.

Regards,
Joe

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
*_______________________________________________*
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit


(Kate Stone) #5

Indeed the install location proves to be the root issue. When LLDB is installed in /usr/bin/lldb we also wind up with content under /usr/lib/lldb that are presumed to be plugins – even though they aren't. When an ASAN enabled library is loaded to initialize the plugin it notices LLDB isn't running with the ASAN runtime and immediately terminates it.

Workarounds: don't install Swift packages in the root directory, or install and then rename /usr/lib/lldb to /usr/lib/lldb-disabled.

A fix for this is being tracked as <rdar://problem/25921276>

Kate Stone k8stone@apple.com <mailto:k8stone@apple.com>
 Xcode Low Level Tools

···

On Apr 25, 2016, at 11:43 AM, Joseph Bell via swift-dev <swift-dev@swift.org> wrote:

What I've found out so far is that the tree built in the 'install' directory (./install/usr) is not suitable to live side-by-side with /usr/ on the host machine. My original approach (documented on http://dev.iachieved.it/iachievedit/) was to ball everything up into a .deb package that installed as an overlay to /usr/, this was just to make it simple to get started.

Now with swift-2.2 and swift-3.0 and the possibility one might want to use both (python2.7, python3), I'm going to change over to placing in /opt/swift/VERSION and provide some alternatives mechanism, OR, use the approach that python2.7, 3, etc. use where there is a /usr/bin/python2.7/, /usr/lib/python2.7/, etc. and /usr/bin/python links back there.

tl;dr: I don't know what occurs exactly but the equivalent of rsync -a ./install/usr/ /usr/ (overlay) causes mayhem for starting the REPL.

On Mon, Apr 25, 2016 at 8:02 AM, Joseph Bell <joe@iachieved.it <mailto:joe@iachieved.it>> wrote:
I've just noticed (thanks to you Ryan) that compiler-rt is indeed checked out and included in the 14.04 build but not the 15.10. I'm going to rebuild from the ground up on 15.10 to see if it grabs compiler-rt and reproduces, as this is being checked out by the ci.swift.org <http://ci.swift.org/> CI server.

This error occurs before any downstream packaging (deb) and is failing the build itself (on the test REPL, it can't even load). Will report back in a bit.

Joe

On Mon, Apr 25, 2016 at 7:52 AM, Ryan Lovelett <swift-dev@ryan.lovelett.me <mailto:swift-dev@ryan.lovelett.me>> wrote:
On Sun, Apr 24, 2016, at 05:44 PM, Joseph Bell via swift-dev wrote:

Well, I thought the REPL issues had all been put to rest, but now I am seeing this on Ubuntu 14.04 (15.10 I do not see it):

➜ package-swift-3.0 git:(swift-3.0) ✗ ./install/usr/bin/swift
==18928==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

This is with the "master" branches that build Swift 3.0, hashes:

$ swift swiftrevs.swift
swift:95e3be665d
llvm:752e1430fc
clang:1e6cba3ce3
lldb:a38bed5855
compiler-rt:a897309947
cmark:5af77f3c1d
llbuild:ea9fd78a4a
swiftpm:22954afe9f
swift-corelibs-xctest:efdde9849c
swift-corelibs-foundation:d2dc9f3cf9
swift-integration-tests:98f6c6d992
swift-corelibs-libdispatch:65330e06d9

Is anyone else building the world on Ubuntu 14.04 that can verify this?

I have seen this behavior many times in many scenarios. Almost always it has to do with a build parameter.

Recently I have noticed that compiling with the "compiler-rt" project seems to cause this issue frequently. I do not understand what "compiler-rt" is, or what its value to Swift is, so I just omit it from my builds. It maybe worth while to do the same and rebuild and see if it goes away.

I would think that if "compiler-rt" is the source of the issues then something likely needs to be submitted to bugs.swift.org <http://bugs.swift.org/>.

Another thing to check is if your packaging Swift (dep, rpm, pacman, etc...) that you are do not strip symbols from binaries and libraries as part of packaging.

Regards,
Joe

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit

--
Joseph Bell
http://dev.iachieved.it/iachievedit/
@iachievedit
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev