tests of 1.7 fail on Ubuntu x86_64

[GoogleCodeExporter]

Amazingly, nobody reported them before me.
I got these on x86_64 architecture with 2.6.38-8-generic kernel running in 
VirtualBox.

Below are failure lines from the log.

--- log ---
FAIL: debugallocation_test.sh
FAIL: heap-checker_unittest.sh
FAIL: heap-checker-death_unittest.sh
FAIL: heap-checker_debug_unittest.sh
FAIL: profiler_unittest.sh
5 of 41 tests failed

Original issue reported on code.google.com by yuriv...@yahoo.com on 5 Jun 2011 at 6:49

[GoogleCodeExporter]

I think it's not been reported before because other people haven't been seeing 
it.  (Maybe the problems are due to VirtualBox?  I don't know what that is.)

It would help if you attached the entire output of 'make check'

Original comment by csilv...@gmail.com on 6 Jun 2011 at 9:12

• Added labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Attaching the log with 5 failures.

VirtualBox is the virtualization environment from Oracle (previously Sun) 
allowing to run one operating systems on another 
(http://en.wikipedia.org/wiki/VirtualBox).
In this case, I am running Ubuntu x86_64 with the kernel 2.6.38-8-generic as a 
guest on FreeBSD host.
For most practical purposes, the fact that OS is run as a guest in the 
virtualization environment shouldn't make any difference.

Original comment by yuriv...@yahoo.com on 7 Jun 2011 at 8:21

Attachments:

• check1.log.gz

[GoogleCodeExporter]

I see output like this:
---
Leak of 280 bytes in 7 objects allocated from:
        @ 409563 
        @ 409667 
        @ 408409 
        @ 2b7363b51d8c 
        @ 2b73645f204d 
Leak of 168 bytes in 3 objects allocated from:
        @ 4052b6 
        @ 4083c0 
        @ 2b7363b51d8c 
        @ 2b73645f204d 
Leak of 120 bytes in 3 objects allocated from:
        @ 409563 
        @ 409667 
        @ 408432 
        @ 2b7363b51d8c 
        @ 2b73645f204d 
Leak of 8 bytes in 1 objects allocated from:
        @ 4052b6 
        @ 408677 
        @ 2b7363b51d8c 
        @ 2b73645f204d 
Leak of 4 bytes in 1 objects allocated from:
        @ 4052b6 
        @ 40868c 
        @ 2b7363b51d8c 
        @ 2b73645f204d
---
which makes me suspicious that the symbolizing isn't working properly.  This is 
a pretty common occurrence, because the OS or toolchain environment can 
apparently do lots of things that make the symbolizer fail.  Other of the tests 
I see failing seem, likewise, to be result of lack of symbol information.  (The 
profiler test failure is because of a spurious 0x00000000 in the backtrace and 
is probably unrelated.  My guess is it's just an artifact of running in the 
virtualization environment.)

You'll have to do some digging to see what might be going on there.  The 
easiest way might be to try running './debugallocation_test 15', which was 
failing because it couldn't symbolize main().  You can then try to follow 
through the commands that pprof runs -- nm and addr2line and the like -- and 
see why it might not be able to use those to resolve symbols.

Original comment by csilv...@gmail.com on 7 Jun 2011 at 9:25

[GoogleCodeExporter]

'./debugallocation_test 15' returns errors, see an attached file 
debugallocation.txt.

'nm --demangle .libs/debugallocation_test' prints output in attached file 
nm.txt.
'echo "0000000000401700" | addr2line --demangle -f -C -e 
.libs/debugallocation_test' prints this:
/home/yuri/google-perftools-1.7/src/tests/debugallocation_test.cc:303

I can't see what is wrong with these command outputs.

Original comment by yuriv...@yahoo.com on 9 Jun 2011 at 8:58

Attachments:

• debugallocation.txt
• nm.txt

[GoogleCodeExporter]

Ah, it looks like another person has reported this, possibly:
   http://code.google.com/p/google-perftools/issues/detail?id=312#c15

Are you also seeing "No shared libraries detected"?  I'm guessing not based on 
your nm output.

This is very weird:

    @ 0x7f85013b0eff __libc_start_main
    @ 0x400c59 _start

Why is it not seeing the call to main()?  Is it being optimized out?  Is this 
just how virtualbox does its thing?  (Unlikely but possible.)  It might be 
interesting to run that test in gdb and see what *it* thinks the stacktrace is 
at that failing call.

Original comment by csilv...@gmail.com on 9 Jun 2011 at 10:01

[GoogleCodeExporter]

No, I am not getting "No shared libraries detected" error.

'main' function is in the executable, judging by this line in nm.txt:
0000000000401700 T main

VirtualBox runs linux pretty much the same way as it would run on hardware. 
This is the whole point. The only side effects that could be observed are that 
it may not see some devices, like USB, unless they are enabled by user. Also 
there is ~10% slowdown compared to running on hardware. But there should be no 
side effects that would matter to pertools.

Attaching gdb stack at the moment of failure (gdb.log).

Original comment by yuriv...@yahoo.com on 10 Jun 2011 at 1:31

Attachments:

• gdb.log

[GoogleCodeExporter]

I'm sorry, I led you down the wrong path in comment 5.  It turns out we 
commonly see __libc_start_main instead of main.  debugallocation_test.cc has:
     IF_DEBUG_EXPECT_DEATH(exit(0), " @ .*main");
which matches __libc_start_main.

It looks like this is fixed in svn-root though not in perftools 1.7.  I wonder 
if the other bugs here fall into the same category.  How easy is it for you to 
try your tests again against the svn-root version of perftools?

Original comment by csilv...@gmail.com on 10 Jun 2011 at 6:34

[GoogleCodeExporter]

Did you mean svn trunk?

There are 4 test failing, please see log attached.
'./debugallocation_test 15' command stil fails with __libc_start_main error.

Original comment by yuriv...@yahoo.com on 10 Jun 2011 at 8:02

Attachments:

• check.log.gz

[GoogleCodeExporter]

Sorry for the delay in replying.

Yes, I did mean svn trunk.

What happens when you run
   ./debugallocation_test 15
against svn trunk?

Original comment by csilv...@gmail.com on 15 Jun 2011 at 10:13

[GoogleCodeExporter]

Haven't heard anything in a while, so closing.  Feel free to reopen if (when) 
you have more info!

Original comment by csilv...@gmail.com on 18 Oct 2011 at 6:26

• Changed state: CannotReproduce