Did we accidentally post an ASan-enabled LLDB?

Comment by Joel Saltzman (JIRA)

I'm not sure. How can I check for you?

I, hm. I'm not sure either. @AnnaZaks, granataenrico (JIRA User)?

Looks like the new warning we added in ASan.

Most likely a library that has been built with ASan is being dlopened. We can check if a library has been built with ASan by checking if it's been linked against the ASan runtime:
$ otool -L ~/tmp/a.out | grep "libclang_rt.asan_osx_dynamic.dylib"
@rpath/libclang_rt.asan_osx_dynamic.dylib (compatibility version 0.0.0, current version 0.0.0)

Comment by Joel Saltzman (JIRA)

Is there a certain path that I can check? Or should I wait for the next release?

Comment by Jay Buffington (JIRA)

Still broken in swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu14.04.tar.gz

Comment by Kate Stone (JIRA)

I have our swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a-ubuntu14.04.tar.gz snapshot installed on an ubuntu14.04 machine and the REPL works normally, so I suspect there's something else in play here.

Comment by Kate Stone (JIRA)

Since this doesn't happen to everyone chances are one or more system libraries have been built using ASAN and are getting loaded by the REPL. You can debug the dynamic library loading process and hopefully get more insight into where the failure is occurring with the following from the snapshot's root directory:

LD_DEBUG=files usr/bin/lldb --repl

This will start the debugger in REPL mode (swift is just a wrapper that does essentially the same thing) with the dynamic linker's debugging mode engaged. It should print out progress as it finds and initializes each library so you can see what library is failing to initialize.

Hi Joel,

I just straightened out some issues with importing modules in the REPL on Ubuntu 15.10 (and Ubuntu 14.04) this past weekend. Can you try this again with a clean build directory? (Those fixes were listed in SR-1109 - they would become problematic at some point when using the REPL on Ubuntu, even if they weren't what you were hitting directly).

If you continue to have trouble, please post the exact build-script line you are using to do the build, along with the hashes you are synched against for each of the repositories.

Thanks!

Comment by Kate Stone (JIRA)

We've now seen the failure even without the REPL involved, just launching LLDB will trigger this problem on an affected machine so I don't think this experiment is needed. The current working theory is that installing the snapshot package to the root directory ✔ is what leads to this problem, though I'm still interested in the exact mechanism and will be investigating further.

Yes, I'd be very skeptical of installing the package to Root. Before we went public, I had us pull out references to doing that in the "How to use on Ubuntu" instructions because (1) we haven't tested that heavily, (2) installing in root is inherently the kind of thing that should be done by somebody making official packages for the system, where it really gets tested against a live system, (3) it seems likely to conflict if a system has clang/llvm installed or any other components that are .so files and/or lay down other static resources we look at, but are for "straight clang" vs. "the clang we build and use from LLDB that match the Swift build we made", etc. It's definitely not a tested configuration and I'm sure there are some gotchas there. As an aside, there is also a readline.so Python module that will quite likely clobber the system Python readline.so package, which is definitely not something you want to have happen. (The Ubuntu readline.so is used by LLDB to suppress a conflict between system Python readline.so pulling in the GNU readline module, which cannot co-exist with libedit, which LLDB and the REPL pull in when python is executed within LLDB).

Eventually we look forward to somebody doing some real packaging for Linux distributions, during which I expect some of these issues would be (need to be) resolved.

Comment by Kate Stone (JIRA)

Indeed this proved 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>

Comment by Joel Saltzman (JIRA)

mv /usr/lib/lldb /usr/lib/lldb-disabled

This did indeed fix the problem. Thank you!

Comment by Kate Stone (JIRA)

Fixed upstream (Committed revision 267749.)

Cherry picked to master:
commit ec12d4930bf8a7d19c22da4ae2bea405b464a4a7 (HEAD -> master, origin/master, origin/HEAD)
Author: Kate Stone <katherine.stone@apple.com>
Date: Wed Apr 27 10:49:51 2016

Renamed system plugin directory to address https://bugs.swift.org/browse/SR-1093