Same problem here, with development snapshot from December 18, 2018 (also on Ubuntu 18.04).

Comment by Jeremy Fillingim (JIRA)

An install of the new 5.0 swift release results in the same type of error (Ubuntu 18.04.2 LTS).

λ › swift
error: ld-2.27.so 0xffffffff0005c564: adding range [0x1464a-0x146ba) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c564: adding range [0x146d0-0x146d6) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c5c5: adding range [0x1464a-0x146ba) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c5c5: adding range [0x146d0-0x146d6) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
Welcome to Swift version 5.0 (swift-5.0-RELEASE).
Welcome to Swift version 5.0 (swift-5.0-RELEASE).
Type :help for assistance.
  1>

cc @dcci

@compnerd, you know Linux better than I do, have you ever seen something like this?

Comment by Tobia (JIRA)

I just downloaded the release version of 5.0 for Ubuntu 18.04 and I'm seeing the same message.

SR-5920 is a duplicate of, or related to, this issue.

Searching for the error message in Github brings up some old (Jun/Jul 2018) forks of CLang, LLVM, and OpenBSD:

https://github.com/search?q=%22which+has+a+base+that+is+less+than+the+function%22&type=Code

specifically in the file SymbolFileDWARF.cpp

Hrm, the warning implies that the DIE is invalid. But the module is ld.so, which is a binary that we didn't build. I wonder where the debug info for that is originating from. Or perhaps the module name is misleading.

Comment by Eduardo (JIRA)

Got the same issue with Ubuntu 18.0.4 and the release version of swift 5.0.

Comment by David Cardozo (JIRA)

I'm also encountering the same error on a fresh install ubuntu 18.04 with swift 5.0

Can any of you folks try with a nightly toolchain downloaded from swift.org and report?
If it still reproduces, I'm going to take a look as it's lldb spitting this error.

Also, cc @adrian-prantl and friss (JIRA User) who have a better understanding of the DWARF parser.

Which host compiler did you use to compile the toolchain?

Comment by David Cardozo (JIRA)

```
dgromov@Predator-G3-571 ~> swift
error: ld-2.27.so 0xffffffff0005c564: adding range [0x1464a-0x146ba) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c564: adding range [0x146d0-0x146d6) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c5c5: adding range [0x1464a-0x146ba) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c5c5: adding range [0x146d0-0x146d6) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
Welcome to Swift version 5.0-dev (LLVM f961e3dd74, Swift ff641d3965).
Type :help for assistance.
1>

```

With a dev version I can still reproduce, do you need me to upload the ld.so file?

Trying to follow the basic tutorial, I used tab completion and then completely crashed (SIGABORT).

Comment by Tobia (JIRA)

I just tried the latest master snapshot and I get the same error.

$ ./swift-DEVELOPMENT-SNAPSHOT-2019-04-16-a-ubuntu18.04/usr/bin/swift
error: ld-2.27.so 0xffffffff0005c564: adding range [0x1464a-0x146ba) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c564: adding range [0x146d0-0x146d6) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c5c5: adding range [0x1464a-0x146ba) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
error: ld-2.27.so 0xffffffff0005c5c5: adding range [0x146d0-0x146d6) which has a base that is less than the function's low PC 0x14dc0. Please file a bug and attach the file at the start of this error message
Welcome to Swift version 5.0-dev (LLVM 06f1615069, Swift 844d4df31a).
Type :help for assistance.
{{ 1>}}

I'm on a standard Ubuntu 18.04 x86-64, freshly updated, kernel 4.15.0.

Comment by David Cardozo (JIRA)

Do we have a follow-up on this?

Comment by Andrew Fernandes (JIRA)

When triaging this bug, I think it's important to consider the "outsider, management" point of view.

I have been pushing my employer to experiment (a.k.a. "gain knowledge") of Swift on Linux as part of expanding our narrow Java-centric viewpoint.

This is particularly important with regard to the "Swift for TensorFlow" project!

Having even a "relatively harmless" error/warning such as this pop up makes Swift seem like "amateur hour" to a large number of developers, especially developers-turned-management who may not have much or any Apple development experience at all.

So fixing this "first impressions" bug may have greater consequences for the larger acceptance of Swift on Linux than may first appear, from a purely technical point of view.

Do you have debug symbols for ld.so installed? It looks like LLDB is complaining about inconsistent debug info in the ld.so dynamic linker. If the answer is yes this may either point to a bug in the compiler used to compile ld.so or in LLDB.

Comment by David Cardozo (JIRA)

adfernandes (JIRA User) I share the same view, I was concern that the decision of putting tensorflow on swift was going to put nonapple people outside, we should make efforts to put swift on linux as smooth as possible.

Comment by Andrew Fernandes (JIRA)

Yes, @adrian-prantl, I have the libc6-dbg package installed (Ubuntu 18.04, fully updated) and can confirm that this packing installs the /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.27.so debug symbols.

Does running `llvm-dwarfdump -verify` (You can find it in the llvm build directory of your Swift build tree) on those symbols return the same error? If yes, then that's a bug in the compiler used to compile `ld-2.27.so`. If not, it's more likely an LLDB bug.

On `Ubuntu 18.04`, which my own built lldb, this is what I see.

root@a7c84a26-dc7c-407c-9cad-5c4a3abf5353:~# ./build/Ninja-DebugAssert+stdlib-Debug/lldb-linux-x86_64/bin/lldb --repl
Welcome to Swift version 5.0-dev (LLVM 082dec2e22, Swift 3658b6c786).
Type :help for assistance.
  1> ^D
root@a7c84a26-dc7c-407c-9cad-5c4a3abf5353:~# uname -a
Linux a7c84a26-dc7c-407c-9cad-5c4a3abf5353 4.15.0-43-generic #​46~16.04.1-Ubuntu SMP Fri Dec 7 13:31:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

The problem might be specific to the snapshots, let's see if I can reproduce.

I think we already identified the debug symbols for ld.so to be the culprit. We just don't know whether it's a false positive or a bug in the compiler used to compile ld.so.

With today's toolchain.

root@a7c84a26-dc7c-407c-9cad-5c4a3abf5353:~/snapshot/swift-5.0.1-RELEASE-ubuntu18.04/usr/bin# ./swift 
Welcome to Swift version 5.0.1 (swift-5.0.1-RELEASE).
Type :help for assistance.
  1>  

`llvm-dwarfdump -verify` on `ld.so` emits so many errors that's not even funny.

What compiler was used? Are those just GCC'isms or do they look legitimate?

Subset of the log attached. pat.rtf

If this error bothers people then we should probably downgrade it to a `log`, but the general problem seems to be that `ld.so` is full of verifiers errors.

@adrian-prantl I don't know exactly which compiler was used to compiler ld.so, but I assume that saying it was GCC is a safe bet.

Clang usually leaves an attribute in the top-level compile unit tag with the producer string. GCC perhaps does the same?

> If this error bothers people then we should probably downgrade it to a `log`, but the general problem seems to be that `ld.so` is full of verifiers errors.

I'm not sure I'm convinced. You get this error when you installed the debug symbols for ld.so. My assumption is that a user will only do that if they are planning on debugging ld.so. If debugging ld.so won't work because of malformed debug info, I'd expect the debugger to tell me about it. Or, in other words: How can we suppress this error message without also not suppressing errors that the users care about? How would we know?

Yes, I checked and `ld.so` is built with GCC.

So, we agree that the suggested workaround here is that of uninstalling `libc6-dbg` from ubuntu unless you really need to debug libc and `ld.so`.

<rdar://problem/50558731>

Comment by Andrew Fernandes (JIRA)

@adrian-prantl and @dcci:

> You get this error when you installed the debug symbols for ld.so. My assumption is that a user will only do that if they are planning on debugging ld.so.

> So, we agree that the suggested workaround here is that of uninstalling `libc6-dbg` from ubuntu unless you really need to debug libc and `ld.so`.

While I appreciate each of these suggestions, they really are not feasible, nor desirable. The libc6-dbg symbols are very useful for all sorts of system debugging and profiling. The debug symbols for ld.so are included with the symbols for libc6 because the dynamic linker is actually part of glibc. So if you want to debug system C programs, you need to be able to have the full Monty.

I am not usually a "compiler apologist", but since the "Supported OS" is Ubuntu 18.04 and the base-most-core part of a distro is it's libc, in this case glibc, the debug symbols of ld.so are "nominatively correct" since they are understood by the system compiler, even if they are technically wrong. If an application's particular branch/flavour/implementation of llvm-dwarfdump doesn't like it... well, tough luck.

Most "large application" projects (like language compilers) end up finding quirks and bugs in the OS and need to work around such issues... just look at the gcc or clang build scripts for all the various distros, MacPorts, etc. A sad, but usually unavoidable part of writing a big, honking, complex piece of software that pushes the system to its limits.

I should clarify that we don't really definitively know that the DWARF produced by GCC is actually wrong. It could also be a bug in the LLDB DWARF parser, since LLVM's DWARF parser doesn't find an issue with this debug info entry. If we can find a smaller reproducer we should be able to confirm that it is a bug in the LLDB DWARF parser and either fix it, or just wait until LLDB's transition to the LLVM DWARF parser is complete.

I honestly don't know how to reconcile

> I am not usually a "compiler apologist", but since the "Supported OS" is Ubuntu 18.04 and the base-most-core part of a distro is it's libc, in this case glibc, the debug symbols of ld.so are "nominatively correct" since they are understood by the system compiler, even if they are technically wrong. If an application's particular branch/flavour/implementation of llvm-dwarfdump doesn't like it... well, tough luck.

with this

> You get this error when you installed the debug symbols for ld.so. My assumption is that a user will only do that if they are planning on debugging ld.so. If debugging ld.so won't work because of malformed debug info, I'd expect the debugger to tell me about it. Or, in other words: How can we suppress this error message without also not suppressing errors that the users care about? How would we know?

That said, I don't think any of this matters. If we can find a smaller example of the same error and it's a bug in LLDB we'll just fix it.

Comment by Andrew Fernandes (JIRA)

Still present on swift-5.0.2-RELEASE on Ubuntu 18.04.2.

Comment by Andrew Andkjar (JIRA)

On Ubuntu 18.04.2 with swift-5.02-RELEASE as I don't currently need to debug glibc (fingers crossed it stays that way), this resolved the annoyance:

sudo apt remove libc6-dbg

Comment by Steven Van Impe (JIRA)

I'm still seeing this with the 5.1 release on Ubuntu 18.04.

I would like to kindly ask that you consider making this a high priority bug. The REPL is for Linux what Playgrounds are for macOS. I use it to teach Swift on Linux, and these errors make for a really bad first impression. Literally, the first word a new Swift user sees is "error" 🙁

@swift-ci create

Comment by Mücahit Şenol (JIRA)

NYX (JIRA User) Thanks a lot. This also solves the issue with Swift 5.1 Ubuntu 18.04

sudo apt remove libc6-dbg

Comment by Steven Van Impe (JIRA)

Unfortunately, this still exists in 5.1.2.

I'm not sure I'm convinced. You get this error when you installed the debug symbols for ld.so. My assumption is that a user will only do that if they are planning on debugging ld.so.

I believe this is installed by default, no? I certainly didn't install it knowingly, so either it comes with the base system, or as a dependency of one of Swift's dependencies.

sudo apt remove libc6-dbg

Unfortunately, this also removes valgrind for me, so this isn't really a feasible workaround.

I had a chance to briefly look at this. From comparing the llvm-dwarfdump output with lldb's error messages it looks like LLDB's dwarf parser may be confused and accidentally reading range list entries from an offset that is 336 bytes too low in that DIE.

So from that it looks like it is indeed a bug in LLDB's DWARF parser, not in GCC. LLDB is currently transitioning to use LLVM's libDebugInfo for reading DWARF, which would also fix this issue (it's the same parser as in llvm-dwarfdump).

Comment by Andrew Fernandes (JIRA)

Thank you, @adrian-prantl

For what it’s worth, one of my fears about this but was realized just this week.

I’ve been working with Swift on Linux for an upcoming tensor flow demo and one of the managers saw that error on my screen, scoffed and said dismissively “looks like it’s still a toy” and walked off.

What a great way to win “hearts and minds“. /s 🙁

Comment by Joaquin Alori (JIRA)

Just got started with S4TF and got hit with this same error. Also just signed up to this tracker too, so not sure if comments like the one I'm writing are useful or just noise, sorry if thats the case!

It doesn't help but it also doesn't hurt.

This is a bug in LLDB's internal DWARF parser that is not present in LLVM's DWARF parser but I'm not going to invest time in fixing it, since there is work underway (over the next couple of months) to switch LLDB over to use the LLVM DWARF parser. If anyone is motivated to fix the bug in the LLDB DWARF parser in the mean time I'm happy to review the patch.

Comment by Rex Fenley (JIRA)

I also just ran into this, and like others, I find it very jarring and I don't think this bug will give colleagues confidence.

How close is the parser switch to complete? Is parser change shipping with Swift 5.2?

If not, I'd like to evaluate the difficulty of fixing this.

>"accidentally reading range list entries from an offset that is 336 bytes too low in that DIE."

Byte offset error sounds like a relatively straight forward fix. However, I'm not sure what "DIE" is, would you mind clarifying? Sorry if this is a naive question, I've never touched LLDB nor LLVM codebases before.

> How close is the parser switch to complete? Is parser change shipping with Swift 5.2?

No. You can follow upstream LLDB development on the lldb-dev and lldb-commits mailings on https://lldb.llvm.org/.

> However, I'm not sure what "DIE" is

A DIE is a Debug Information Entry (cf. http://www.dwarfstd.org/Download.php).

Comment by Steven Van Impe (JIRA)

I'm no longer seeing this with Swift 5.2.4 on Ubuntu 20.04.

This problem still exists on Ubuntu 18.04, with the latest Swift 5.4.1.