4 self-checks fail on FreeBSD

[GoogleCodeExporter]

To reproduce:
cd /usr/ports/devel/google-perftools && make check

Version: 0.94

Relevant parts of the log:
<skip>
Testing empty allocation
Sanity-testing all the memory allocation functions
Testing large allocation
Testing calloc
Testing operator new(nothrow).
terminate called after throwing an instance of 'std::bad_alloc'
terminate called recursively
Abort trap
FAIL: tcmalloc_minimal_unittest
<skip>
Testing empty allocation
Sanity-testing all the memory allocation functions
Testing large allocation
Testing calloc
Testing operator new(nothrow).
terminate called after throwing an instance of 'std::bad_alloc'
terminate called recursively
Abort trap
FAIL: tcmalloc_unittest
<skip>
Testing empty allocation
Sanity-testing all the memory allocation functions
Testing large allocation
Testing calloc
Testing operator new(nothrow).
terminate called after throwing an instance of 'std::bad_alloc'
terminate called recursively
Abort trap
FAIL: tcmalloc_both_unittest
<skip>
Testing ./heap-checker_unittest with HEAP_CHECKER_TEST_TEST_LEAK=1
HEAP_CHECKER_TEST_TEST_CANCEL_GLOBAL_CHECK=1 ... FAIL
[: 0: unexpected operator
Output did not match 'Canceling .* whole-program .* leak check$'
Output from failed run:

---
Starting tracking the heap
No shared libs detected. Will likely report false leak positives for
statically linked executables.
Turning heap leak checking off
HeapLeakChecker got turned off; we won't test much...

Original issue reported on code.google.com by visa_des...@yahoo.com on 8 Apr 2008 at 4:03

[GoogleCodeExporter]

In a totally different context, I saw this text by a compiler guru:

} the compiler calls the nothrow version
} of new.  When the compiler does that, by default it checks the return
} value of new for NULL, and throws an exception if it sees one.  

So this may have to do with how much virtual memory you have on your machine.  
What
does 'vmstat' say?

The other two failures (with heap-checker) are known -- heap-checker doesn't 
work on
non-linux system.  This and related constraints are documented in the README and
(especially) the INSTALL file.

Original comment by csilv...@gmail.com on 8 Apr 2008 at 10:50

[GoogleCodeExporter]

> vmstat
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr ad12 cd0   in   sy   cs us sy id
 2 0 0 1205104 230464   951   3   4   2  1034 1380   0   0  215 24075 5228 22  4 74

Original comment by visa_des...@yahoo.com on 9 Apr 2008 at 5:33

[GoogleCodeExporter]

I also believe that exceptions are broken on FreeBSD-7.0 now if you compile 
with the
system compiler. Failures may have been caused by this.

Original comment by visa_des...@yahoo.com on 9 Apr 2008 at 5:36

[GoogleCodeExporter]

Nope, exceptions work ok on FreeBSD. And still 4 self-failures.

I would like to make a suggestion: if some tests are known to fail on some 
platforms
please print this explicitly. This will minimize confusion.

For example:
================================================================================
4 of 22 tests failed, 2 of 4 failures are expected on this platform (see 
INSTALL file
for details)
Please report to opensource@google.com
================================================================================

Original comment by visa_des...@yahoo.com on 9 Apr 2008 at 9:50

[GoogleCodeExporter]

I don't know how to edit the "make test" output (which is generated by
automake) -- but if you do, please feel free to submit a patch!

As for the two failures that raise bad_alloc, I'm unable to reproduce them, so 
I'm
afraid the onus of debugging a bit further will fall to you.  It's tricky to 
debug
this since most of the work is done in libc, but if you can check even that the
new(nothrow) test code is actually calling the nothrow version of new in 
tcmalloc.cc,
that would be a help.  Anything you could do to follow the logic in libc's
exception-handling code, beyond there, when the allocation fails, would be even 
better.

Original comment by csilv...@gmail.com on 9 Apr 2008 at 11:25

[GoogleCodeExporter]

Ok, I will debug this.

Original comment by visa_des...@yahoo.com on 9 Apr 2008 at 11:37

[GoogleCodeExporter]

I am looking into this TestOneNothrowNew case.
It calls the following lines:
1. TestNothrowNew(&::operator new);
2. static void TestNothrowNew(void* (*func)(size_t, const std::nothrow_t&)) {
    ...
    // test with new_handler:
    std::set_new_handler(TestNewHandler);
    TestOneNothrowNew(func); // <----
3. if ((*func)(kTooBig, std::nothrow) != 0) {
4. void* operator new(size_t size, const std::nothrow_t&) __THROW {
     void* p = cpp_alloc(size, true); // <-----
5. static inline void* cpp_alloc(size_t size, bool nothrow) {
     ...
     try {
       (*nh)(); // <---- here it's not caught
     } catch (const std::bad_alloc&) {
       if (!nothrow) throw; // nothrow here is true
       return p;
     }
6. static void TestNewHandler() throw (std::bad_alloc) {
     ++news_handled;
     throw std::bad_alloc(); // <---- here exception is thrown
   }

So exception is thrown from the level 6.
But on level 5 it for some reason isn't caught and it causes:
terminate called after throwing an instance of 'std::bad_alloc'.

Original comment by visa_des...@yahoo.com on 29 Apr 2008 at 2:24

[GoogleCodeExporter]

I think we have to go back to issue 3, that exceptions are broken somehow on 
your
system.  Certainly this test passes on my freebsd 6.0-stable system.  And your
sleuthing has determined that the code is correctly raising the right 
exception, it's
just not being caught for some reason.  So that argues the problem is in the 
libc
exception-handling code somewhere.

Based on that, I'm going to close this as Invalid (meaning it's not a tcmalloc 
bug).
 But if you see evidence the problem actually is somewhere in tcmalloc, please feel
free to reopen.

craig

Original comment by csilv...@gmail.com on 29 Apr 2008 at 7:33

• Changed state: Invalid

[GoogleCodeExporter]

I did some more troubleshooting and found that indeed it was my system that 
caused
the problems related to exceptions.

It was an astray /usr/local/lib/libgcc_s.so.1 not belonging to any package that 
this
testcase was linked to. This libgcc_s.so.1 belonged to some older gcc version 
that
must have been left there by mistake by some ports installed earlier.

But there are 2 other cases that still fail:
FAIL: heap-checker-death_unittest.sh
FAIL: profiler_unittest.sh

Original comment by visa_des...@yahoo.com on 29 Apr 2008 at 8:49