search

CodeJuan / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

heap-profiler check fails when built with gcc 4.8.0 but works when built with gcc 4.4.7 #670

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. ./configure --enable-frame-pointers
2. make
3. make check

What is the expected output? What do you see instead?

Expect all the checks to pass, but heap-profiler_unittest.sh and 
heap-profiler_debug_unittest.sh fail

What version of the product are you using? On what operating system?

version 2.4 of gperftools
linux kernel version: 2.6.32-358.11.1.el6.x86_64

Please provide any additional information below.

The failed version was compiled with gcc version 4.8.0
However it works just fine when compiled with gcc version 4.4.7
Not sure how the compiler version affects this...

Original issue reported on code.google.com by pilot...@gmail.com on 28 Jan 2015 at 10:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for reporting it. BTW how you obtained gcc 4.8 on rhel6. Was that some 
kind of Red hat developer toolset ? Or maybe gcc 4.8 built manually ?

Original comment by alkondratenko on 28 Jan 2015 at 11:12

GoogleCodeExporter commented 9 years ago 
The problem occurred on a cluster on which I am merely a user so I do not
know for sure... however looking at the build options it looks like it was
built manually. I will ask the sys-admin to confirm...

In case it is useful this is the output from gcc -v for the 4.8.0 version:

Reading specs from
/usr/local/gcc-4.8.0/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.0/libexec/gcc/x86_64-unknown-linux-gnu/4.
8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.0/configure --prefix=/usr/local/gcc-4.8.0 CC=gcc
Thread model: posix
gcc version 4.8.0 (GCC)

Then this is the output from the 4.4.7 version:

Reading specs from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/specs
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)

Original comment by pilot...@gmail.com on 28 Jan 2015 at 11:32

GoogleCodeExporter commented 9 years ago 
Hello gperftools developers

      So the sys-admin for the cluster confirmed that gcc was built
from source. Here is his e-mail:

On bugaboo, gcc-4.8.0 was built from source. This is rather old
build and the command to build was simple:
        cd /usr/local/src/gcc-4.8.0-build
        ../gcc-4.8.0/configure --prefix=/usr/local/gcc-4.8.0 CC=gcc
        make bootstrap
        make install

Hope this information will help you. If you need a new version,
we can build it too.

Take Care
Mike

Original comment by pilot...@gmail.com on 29 Jan 2015 at 1:19

GoogleCodeExporter commented 9 years ago 
Hello I tried on a newer compiler on a different computer. This time gcc 4.8.2 
here are the gcc -v options:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/lustre/jasper/software/gcc/gcc-4.8.2/bin/../libexec/gcc/x86
_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/global/software/gcc/gcc-4.8.2 
--enable-shared --enable-threads=posix --enable-checking=release 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-libgcj-multifile --enable-languages=c,c++,fortran 
--enable-java-awt=gtk --disable-dssi --disable-plugin 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
Thread model: posix
gcc version 4.8.2 (GCC)

So this problem is not isolated to 4.8.0

Take Care
Mike

Original comment by pilot...@gmail.com on 29 Jan 2015 at 11:02

GoogleCodeExporter commented 9 years ago 
Looking at errors logs I was able to reproduce the problem and "fix" it.

This seem to be caused by some changes to how gcc may name static functions. 
And older binutils from rhel6 not able to deal with that.

I.e. _ZL8Allocateiii.constprop.2 from profile does not get "demangled" down to 
Allocate which is expected by test.

So it's actually quite harmless in practice.

I was able to reproduce this problem building gcc 4.8.4 (latest) inside centos 
6 docker container. Then when I updated binutils too, failures went away.

Marking as NotABug because it's not a bug that can or should be fixed in 
gperftools. It can be argued that it's not a bug at all (i.e. apparently 
upgrading gcc should include upgrading binutils).

Original comment by alkondratenko on 31 Jan 2015 at 4:59

GoogleCodeExporter commented 9 years ago 
Hello gperftools developers

         Thanks for looking into that. Glad to hear it can be ignored!

Take Care
Mike

Original comment by pilot...@gmail.com on 1 Feb 2015 at 2:45