Debian Bug report logs - #860394
addr2line cannot decode addresses that gdb does

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Vincent Fourmond <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: addr2line cannot decode addresses that gdb does

Date: Sat, 15 Apr 2017 23:12:49 +0200

Package: binutils
Version: 2.28-3
Severity: normal
File: /usr/bin/x86_64-linux-gnu-addr2line

  Dear maintainer,

  I have been using addr2line to debug a C++ program that dumps stack
traces when encountering an exception: I just had to paste the output
to addr2line, and I had what I wanted.

  For some time now (sorry, can't remember when), that doesn't work
anymore, I just have:

~ addr2line -e =QSoas
0x000055c26b7d964a
??:0

  I thought my stack trace output somehow got wrong, but in fact, gdb
understands the address correctly:

~ gdb =QSoas
[...]
(gdb) bt 2
#0  0x000055c274a0cfe0 in ?? ()
#1  0x000055c26b7d964a in FitData::unpackCurrentParameters (this=0x7ffeafc9ff10, target=0x55c26fff3b70)
    at src/fitdata.cc:805

  The QSoas executable is produced via at Qt qmake project. The
linking finishes with the following command:

{ test -n "" && DESTDIR="" || DESTDIR=.; } && test $(gdb --version | sed -e 's,[^0-9][^0-9]*\([0-9]\)\.\([0-9]\).*,\1\2,;q') -gt 72 && gdb --nx --batch --quiet -ex 'set confirm off' -ex "save gdb-index $DESTDIR" -ex quit 'QSoas' && test -f QSoas.gdb-index && objcopy --add-section '.gdb_index=QSoas.gdb-index' --set-section-flags '.gdb_index=readonly' 'QSoas' 'QSoas' && rm -f QSoas.gdb-index || true

  But I guess this just adds an index, and doesn't modify the debug
info anyhow.

  I'll be glad to provide you with any further files.

  Regards,

	Vincent Fourmond

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages binutils depends on:
ii  libc6   2.24-8
ii  zlib1g  1:1.2.8.dfsg-2+b1

binutils recommends no packages.

Versions of packages binutils suggests:
pn  binutils-doc  <none>

-- no debconf information

Message #10 received at [email protected] (full text, mbox, reply):

From: Vincent Fourmond <[email protected]>

To: [email protected]

Subject: Re: Bug#860394: Acknowledgement (addr2line cannot decode addresses that gdb does)

Date: Sun, 16 Apr 2017 16:59:49 +0200

severity -1 minor
thanks

  Dear maintainer,

  Here is some more information:

  I use backtrace (3) to generate the backtrace, and print it more or
less according to the man page. I get outputs in the spirit of:

        0x5612decb8d15: QSoas(+0x173d15) [0x5612decb8d15]
        0x5612dec665c3: QSoas(+0x1215c3) [0x5612dec665c3]
        0x5612dec66d2f: QSoas(+0x121d2f) [0x5612dec66d2f]

  I used to be able to copy-paste directly to addr2line and get
something useful, but I just found out that it still works if I only
copy-paste what is within the parentheses. Is that a kernel change
(which makes text address not predictable ?).

  Downgrading since it seems reasonably easy to work around.

  Best regards,

      Vincent Fourmond

On Sat, Apr 15, 2017 at 11:15 PM, Debian Bug Tracking System
<[email protected]> wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Matthias Klose <[email protected]>
>
> If you wish to submit further information on this problem, please
> send it to [email protected].
>
> Please do not send mail to [email protected] unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 860394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860394
> Debian Bug Tracking System
> Contact [email protected] with problems

Message #15 received at [email protected] (full text, mbox, reply):

From: John Ogness <[email protected]>

To: Vincent Fourmond <[email protected]>

Cc: [email protected]

Subject: Re: Bug#860394: Acknowledgement (addr2line cannot decode addresses that gdb does)

Date: Tue, 16 Jan 2018 17:06:42 +0100

On 2017-04-16, Vincent Fourmond <[email protected]> wrote:
>   I use backtrace (3) to generate the backtrace, and print it more or
> less according to the man page. I get outputs in the spirit of:
>
>         0x5612decb8d15: QSoas(+0x173d15) [0x5612decb8d15]
>         0x5612dec665c3: QSoas(+0x1215c3) [0x5612dec665c3]
>         0x5612dec66d2f: QSoas(+0x121d2f) [0x5612dec66d2f]
>
>   I used to be able to copy-paste directly to addr2line and get
> something useful, but I just found out that it still works if I only
> copy-paste what is within the parentheses. Is that a kernel change
> (which makes text address not predictable ?).

There are 2 things going on. First, by default gcc is now building
executables as position independent (-pie). This can be explicitly
disabled with the -no-pie linking option. Disabling PIE should result in
things working as they did before.

The second thing going on is Address Space Layout Randomization
(ASLR). This is now active by default and will cause all PIE executables
to be loaded to random addresses. This can be disabled globally with
sysctl:

    $ sudo sysctl -w kernel.randomize_va_space=0

Or with a boot argument:

    norandmaps

Or (preferrably) locally for the process you are interested:

    $ setarch `uname -m` -R /some/program

Often it is convenient to use the above command with /bin/bash so as to
quickly create a non-randomized environment for yourself.

However, be aware that even when ASLR is disabled, if it is a PIE
exectuable, it will always load to the same address, but that is not the
address within the executable. That means that for PIE executables, many
binutils (such as addr2line) will require you to recalculate the offset.

You can view the loaded offsets using the dynamic loader:

   $ LD_TRACE_PRELINKING=1 /some/program | grep '=>'

John Ogness

Send a report that this bug log contains spam.