Comment 2 for bug 415424

The problem is that when the library was built the CRC of the debug symbols file gets planted in the main library file. OProfile very sensibly checks that the CRC of the debug file matches that stored in the actual library and ignores it if it doesn't.

GDB may well work and having hacked oprofile to ignore the embedded CRC in library it *seems* to give correct results. Of course it's hard to be sure because the -dbg symbols look as though they were created at a different time to the actual library. If I look at the opreport -V bfd output on the same library on my Gentoo system (where I know the striped symbol-file was created at the same time as the library) I can see the CRC's match and everything is fine.

Picking a random example (libc) I see the following when running "opreport -V bfd":

looking for debugging file libc-2.7.so with crc32 = 9587b62d
separate_debug_file_exists: /lib/.debug/libc-2.7.so give img_path/lib/.debug/libc-2.7.so
separate_debug_file_exists: /usr/lib/debug/lib/libc-2.7.so give img_path/usr/lib/debug/lib/libc-2.7.so
found /usr/lib/debug/lib/libc-2.7.so with crc32 = 9587b62d
now loading: /usr/lib/debug/lib/libc-2.7.so

And you can see the CRC of the debug libc matches so we can be confident of the results offered by oprofile (and gdb for that matter).

As I stated in the original report this may be an artifact of the build process that creates packages however I don't really have an understanding of the Ubuntu build farm. Perhaps there is someone on the infrastructure team that could give some input.

The versions of libcairo2 involved are:

11:05 root@vnms/x86_64 [vnms] >dpkg --status libcairo2 libcairo2-dbg
Package: libcairo2
Status: deinstall ok installed
Priority: optional
Section: libs
Installed-Size: 828
Maintainer: Ubuntu Core Developers <email address hidden>
Architecture: amd64
Source: cairo
Version: 1.6.0-0ubuntu2
Replaces: libcairo0.5.1, libcairo0.6.0, libcairo0.9.0, libcairo1
Provides: libcairo
Depends: libc6 (>= 2.4), libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:4.1.1-21), libpixman-1-0 (>= 0.10.0), libpng12-0 (>= 1.2.13-4), libstdc++6, libx11-6, libxrender1, zlib1g (>= 1:1.2.3.3.dfsg-1)
Conflicts: libcairo1
Description: The Cairo 2D vector graphics library
 Cairo is a multi-platform library providing anti-aliased
 vector-based rendering for multiple target backends. Paths consist
 of line segments and cubic splines and can be rendered at any width
 with various join and cap styles. All colors may be specified with
 optional translucence (opacity/alpha) and combined using the
 extended Porter/Duff compositing algebra as found in the X Render
 Extension.
 .
 Cairo exports a stateful rendering API similar in spirit to the path
 construction, text, and painting operators of PostScript, (with the
 significant addition of translucence in the imaging model). When
 complete, the API is intended to support the complete imaging model of
 PDF 1.4.
 .
 This package contains the shared libraries.
Homepage: http://cairographics.org/
Original-Maintainer: Dave Beckett <email address hidden>

Package: libcairo2-dbg
Status: install ok installed
Priority: extra
Section: libdevel
Installed-Size: 1648
Maintainer: Ubuntu Core Developers <email address hidden>
Architecture: amd64
Source: cairo
Version: 1.6.0-0ubuntu2
Depends: libcairo2 (= 1.6.0-0ubuntu2)
Description: The Cairo 2D vector graphics library (debugging symbols)
 Debugging symbols for the Cairo 2D vector graphics library. This is
 needed to debug programs linked against libcairo2.
Homepage: http://cairographics.org/
Original-Maintainer: Dave Beckett <email address hidden>

Hey the worst case scenario is that some Black Hat attacker has built their own version of libcairo, somehow subverted the signing keys and penetrated the Ubuntu servers and uploaded a compromised library but never bother with the -dbg .deb package. It's fairly unlikely but its the only explanation for mismatched CRC's I can think of at the moment.