[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#661193: marked as done (linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions)

Your message dated Sat, 1 May 2021 14:41:46 +0200
with message-id <YI1MiizmjOID/+Ti@eldamar.lan>
and subject line Re: Bug#661193: linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions
has caused the Debian Bug report #661193,
regarding linux-tools-3.2: perf fails to annotate code with separate debug info under some conditions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
661193: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661193
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-tools-3.2
Version: 3.2.1-2
Severity: normal

Hi!

perf report does not show source code lines (annotation) for some
binaries with separate debug information if those build-id's have been
cached in perf's build-id cache. This is true for at least those
packages whose debug symbols are installed in
/usr/lib/debug/path/binary and not in
/usr/lib/debug/.build-id/.../$hash. For example, e2fslibs, e2fsprogs
and I believe very many others packages are affected by this (the
mentioned packages even after fixing their -dbg packages per #661071).

This manifests with the following symptoms. If you want to test this,
I suggest either waiting for a fix for #661071 to be uploaded or to
choose a different package from e2fsprogs and its corresponding -dbg
package (but not one where the -dbg package has files in the .build-id
directory):

------------------------------------------------------------
1. Compile a package with separate debug info (so that you have the
sources available actually) and install both the package and the -dbg
package. Use a binary from the package in place of dumpe2fs in
following steps.

2. Run perf record -g dumpe2fs $some_fs_image

3. Run perf annotate

NOTE: functions in e.g. libext2fs.so.2.4 or in dumpe2fs are not
annotated with source code lines

4. run perf buildid-list. Note that it lists binaries for those
non-annotated functions. Either find the file in the
~/.debug/.build-id directory tree, or investigate using
perf annotate -vv (grep for "Executing:") where the file file
resides.

5. Note that the file you found is a copy of the binary or the library
in question, *not* a copy of the relevant file from /usr/lib/debug.
The objdump command that perf reports executing does not annotate it
with source code lines. If you try that same line but replace the
filename with the path to the actual binary, objdump knows where to
find the debug info and does annotate it.

6. mv perf.data perf.data.tmp

7. perf record -g ls

(this step is important because it empties the build-id cache and
populates it with objects needed for the ls execution; turns out perf
handles annotating fine once the relevant object is no longer in the
build-id cache)

8. perf annotate -i perf.data.tmp

NOTE: the functions that were unannotated in step 3 in that old
perf.data are now correctly annotated with source code.
------------------------------------------------------------

I think the actual bug is that, for some reason, in step 2 perf record
copies the non-debug version to the build-id cache instead of the
debug version. I have not investigated why this happens.

I also tried to remove the wrong file from the build-id cache and
re-add the correct one with perf buildid-cache -v
--remove=1a22c5f5c7a51ede62d01eeba1de59c15e7c9325; perf buildid-cache
--add=/path/to/file, but for some reason I couldn't get that --remove=
command to actually remove anything from the cache.

	Sami


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.4 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-tools-3.2 depends on:
ii  libc6         2.13-26
ii  libdw1        0.152-1+b1
ii  libelf1       0.152-1+b1
ii  libnewt0.52   0.52.14-8
ii  libperl5.14   5.14.2-7
ii  libpython2.7  2.7.2-13
ii  libslang2     2.2.4-6
ii  perl          5.14.2-7
ii  python        2.7.2-10

Versions of packages linux-tools-3.2 recommends:
ii  linux-base  3.4

Versions of packages linux-tools-3.2 suggests:
pn  linux-doc-3.2  <none>

-- no debconf information

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message --- 
Source: linux
Source-Version: 4.4~rc4-1~exp1

On Sat, Nov 07, 2015 at 09:52:54AM +0100, Sven Joachim wrote:
> Control: found -1 linux-tools/4.2-2
> Control: tags -1 + fixed-upstream
> 
> On 2012-02-24 23:11 +0100, Sami Liedes wrote:
> 
> > Package: linux-tools-3.2
> > Version: 3.2.1-2
> > Severity: normal
> >
> > Hi!
> >
> > perf report does not show source code lines (annotation) for some
> > binaries with separate debug information if those build-id's have been
> > cached in perf's build-id cache. This is true for at least those
> > packages whose debug symbols are installed in
> > /usr/lib/debug/path/binary and not in
> > /usr/lib/debug/.build-id/.../$hash. For example, e2fslibs, e2fsprogs
> > and I believe very many others packages are affected by this (the
> > mentioned packages even after fixing their -dbg packages per #661071).
> 
> This should be fixed in Linus' tree with commit
> 5baecbcd9c9a2f491afe1369fc22e7363f9c94d5[1], but I haven't tested it.

There was no confirmation, but given the age of the bug I'm now
considering this was the case and mark it as closed. Please reopen in
case this is still a problem.

Regards,
Salvatore

--- End Message ---
Reply to: