[Bug 1759248] [NEW] addr2line wrong search path for debug files
Juan Navarro
oneorjuan at gmail.com
Tue Mar 27 11:53:37 UTC 2018
Public bug reported:
I cannot make `addr2line` to work. It does look for symbols at three (*unexisting*) paths:
/usr/bin/*.debug
/usr/bin/.debug/*.debug
/usr/lib/debug/usr/bin/*.debug
But it just seems to ignore the path where all debugging symbols are actually installed by default:
/usr/lib/debug/.build-id/
I run `addr2line` like this:
addr2line -f -C -e <PathToExecFile> <Addr>
Am I missing some configuration switch, system option, or anything
similar?
------------
Now some proofs for what I'm stating.
Here, I'll be using the program `screen` as an example:
$ sudo apt-get install screen screen-dbg
$ file /usr/bin/screen
> /usr/bin/screen: setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=e9d3cd5073daa6b7365b3787673143edeec589d3, stripped
$ dpkg -L screen-dbg
> /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
Here we empirically found out where the debug symbols for `screen` are:
/usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
Now we run `strace addr2line` to see where it tries to access...
# Get any valid object address
$ objdump -T /usr/bin/screen
> 00000000006697e0
# Use the object address in addr2line
$ strace -f addr2line -f -C \
-e /usr/bin/screen 0x00000000006697e0 2>&1 | grep debug
> open("/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/bin/.debug/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
Here we see the 3 paths I mentioned earlier, but no signs of the desired
one.
------------
Additional information:
- Ubuntu release
$ lsb_release -rd
> Description: Ubuntu 16.04.4 LTS
Release: 16.04
- Package version
$ apt-cache policy binutils
> binutils:
Installed: 2.26.1-1ubuntu1~16.04.6
Candidate: 2.26.1-1ubuntu1~16.04.6
Version table:
*** 2.26.1-1ubuntu1~16.04.6 500
500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
100 /var/lib/dpkg/status
2.26-8ubuntu2 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
- What I expected to happen
I expected that the `strace` command shown avobe would access the debug files at their actual location:
/usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
- What happened instead
The `addr2line` program does look for the debug file at three unexisting locations:
/usr/bin/*.debug
/usr/bin/.debug/*.debug
/usr/lib/debug/usr/bin/*.debug
but it does not look for the debug file at the correct location.
** Affects: binutils (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
I cannot make `addr2line` to work. It does look for symbols at three (*unexisting*) paths:
- /usr/bin/*.debug
- /usr/bin/.debug/*.debug
- /usr/lib/debug/usr/bin/*.debug
+ /usr/bin/*.debug
+ /usr/bin/.debug/*.debug
+ /usr/lib/debug/usr/bin/*.debug
But it just seems to ignore the path where all debugging symbols are actually installed by default:
- /usr/lib/debug/.build-id/
+ /usr/lib/debug/.build-id/
I run `addr2line` like this:
- addr2line -f -C -e <PathToExecFile> <Addr>
+ addr2line -f -C -e <PathToExecFile> <Addr>
Am I missing some configuration switch, system option, or anything
similar?
------------
Now some proofs for what I'm stating.
Here, I'll be using the program `screen` as an example:
- $ sudo apt-get install screen screen-dbg
- $ file /usr/bin/screen
- > /usr/bin/screen: setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
- dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
- BuildID[sha1]=e9d3cd5073daa6b7365b3787673143edeec589d3, stripped
- $ dpkg -L screen-dbg
- > /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
+ $ sudo apt-get install screen screen-dbg
+ $ file /usr/bin/screen
+ > /usr/bin/screen: setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
+ dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
+ BuildID[sha1]=e9d3cd5073daa6b7365b3787673143edeec589d3, stripped
+ $ dpkg -L screen-dbg
+ > /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
Here we empirically found out where the debug symbols for `screen` are:
- /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
+ /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
Now we run `strace addr2line` to see where it tries to access...
- # Get any valid object address
- $ objdump -T /usr/bin/screen
- > 00000000006697e0
-
- # Use the object address in addr2line
- $ strace -f addr2line -f -C \
- -e /usr/bin/screen 0x00000000006697e0 2>&1 | grep debug
- > open("/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/bin/.debug/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
- open("/usr/lib/debug/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
+ # Get any valid object address
+ $ objdump -T /usr/bin/screen
+ > 00000000006697e0
+
+ # Use the object address in addr2line
+ $ strace -f addr2line -f -C \
+ -e /usr/bin/screen 0x00000000006697e0 2>&1 | grep debug
+ > open("/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
+ open("/usr/bin/.debug/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
+ open("/usr/lib/debug/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
Here we see the 3 paths I mentioned earlier, but no signs of the desired
one.
------------
Additional information:
- Ubuntu release
$ lsb_release -rd
> Description: Ubuntu 16.04.4 LTS
Release: 16.04
- Package version
$ apt-cache policy binutils
> binutils:
Installed: 2.26.1-1ubuntu1~16.04.6
Candidate: 2.26.1-1ubuntu1~16.04.6
Version table:
*** 2.26.1-1ubuntu1~16.04.6 500
500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
100 /var/lib/dpkg/status
2.26-8ubuntu2 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
- What I expected to happen
I expected that the `strace` command shown avobe would access the debug files at their actual location:
- /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
+ /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
- What happened instead
The `addr2line` program does look for the debug file at three unexisting locations:
- /usr/bin/*.debug
- /usr/bin/.debug/*.debug
- /usr/lib/debug/usr/bin/*.debug
+ /usr/bin/*.debug
+ /usr/bin/.debug/*.debug
+ /usr/lib/debug/usr/bin/*.debug
but it does not look for the debug file at the correct location.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1759248
Title:
addr2line wrong search path for debug files
Status in binutils package in Ubuntu:
New
Bug description:
I cannot make `addr2line` to work. It does look for symbols at three (*unexisting*) paths:
/usr/bin/*.debug
/usr/bin/.debug/*.debug
/usr/lib/debug/usr/bin/*.debug
But it just seems to ignore the path where all debugging symbols are actually installed by default:
/usr/lib/debug/.build-id/
I run `addr2line` like this:
addr2line -f -C -e <PathToExecFile> <Addr>
Am I missing some configuration switch, system option, or anything
similar?
------------
Now some proofs for what I'm stating.
Here, I'll be using the program `screen` as an example:
$ sudo apt-get install screen screen-dbg
$ file /usr/bin/screen
> /usr/bin/screen: setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=e9d3cd5073daa6b7365b3787673143edeec589d3, stripped
$ dpkg -L screen-dbg
> /usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
Here we empirically found out where the debug symbols for `screen` are:
/usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
Now we run `strace addr2line` to see where it tries to access...
# Get any valid object address
$ objdump -T /usr/bin/screen
> 00000000006697e0
# Use the object address in addr2line
$ strace -f addr2line -f -C \
-e /usr/bin/screen 0x00000000006697e0 2>&1 | grep debug
> open("/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/bin/.debug/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/debug/usr/bin/d3cd5073daa6b7365b3787673143edeec589d3.debug", O_RDONLY) = -1 ENOENT (No such file or directory)
Here we see the 3 paths I mentioned earlier, but no signs of the
desired one.
------------
Additional information:
- Ubuntu release
$ lsb_release -rd
> Description: Ubuntu 16.04.4 LTS
Release: 16.04
- Package version
$ apt-cache policy binutils
> binutils:
Installed: 2.26.1-1ubuntu1~16.04.6
Candidate: 2.26.1-1ubuntu1~16.04.6
Version table:
*** 2.26.1-1ubuntu1~16.04.6 500
500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages
100 /var/lib/dpkg/status
2.26-8ubuntu2 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
- What I expected to happen
I expected that the `strace` command shown avobe would access the debug files at their actual location:
/usr/lib/debug/.build-id/e9/d3cd5073daa6b7365b3787673143edeec589d3.debug
- What happened instead
The `addr2line` program does look for the debug file at three unexisting locations:
/usr/bin/*.debug
/usr/bin/.debug/*.debug
/usr/lib/debug/usr/bin/*.debug
but it does not look for the debug file at the correct location.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1759248/+subscriptions
More information about the foundations-bugs
mailing list