10.6 SL : pointer being freed was not allocated

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build and link code on MacOS X 10.6 GM
2. Run any test code with or without debugger

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

1. If code is run without a debugger, the following errors appear in the 
terminal, EVERY time 
there is text to display:

<proc>(27319) malloc: *** error for object 0x7fff70ca5500: pointer being freed 
was not 
allocated
*** set a breakpoint in malloc_error_break to debug

The tests will still run, as the SIGABRT is being caught by gtest, but the 
error will persist.

2. If the code is run with a debugger, here is the following output:

<proc>(27319) malloc: *** error for object 0x7fff70ca5500: pointer being freed 
was not 
allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal:  “SIGABRT”.

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

GTest 1.3.0, 10.6 Snow Leopard (10A432)

Please provide any additional information below.

There seems to be some funny interaction with the libstdc++ and gtest 1.3.0. 
10.5.x (all 
versions) work perfectly with gtest 1.3.0

Original issue reported on code.google.com by robdotso...@gmail.com on 31 Aug 2009 at 3:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Actually, the problem seems to be isolated in the init functions for the 
framework. Here is the GDB backtrace:

#0  0x00007fff80c37096 in __kill ()
#1  0x00007fff80cd80c2 in abort ()
#2  0x00007fff80bef215 in free ()
#3  0x0000000100054527 in __gnu_cxx::new_allocator<char>::deallocate 
(this=0x7fff5fbfcdaf, 
__p=0x7fff70ca5500 "") at new_allocator.h:97
#4  0x0000000100054572 in std::string::_Rep::_M_destroy (this=0x7fff70ca5500, 
__a=@0x7fff5fbfce0f) at 
basic_string.tcc:431
#5  0x0000000100055a17 in std::string::_Rep::_M_dispose (this=0x7fff70ca5500, 
__a=@0x7fff5fbfce0f) at 
basic_string.h:238
#6  0x0000000100055a4e in std::basic_string<char, std::char_traits<char>, 
std::allocator<char> 
>::~basic_string (this=0x7fff5fbfce40) at basic_string.h:493
#7  0x000000010006f097 in std::basic_stringbuf<char, std::char_traits<char>, 
std::allocator<char> 
>::overflow (this=0x100200098, __c=103) at sstream.tcc:125
#8  0x000000010006dd2c in std::basic_streambuf<char, std::char_traits<char> 
>::xsputn 
(this=0x100200098, __s=0x10002d264 "gtest_", __n=6) at streambuf.tcc:102
#9  0x00007fff85f73ae4 in std::__ostream_write<char, std::char_traits<char> > ()
#10 0x00007fff85f71b98 in std::__ostream_insert<char, std::char_traits<char> > 
()
#11 0x00007fff85f71c58 in std::operator<< <std::char_traits<char> > ()
#12 0x0000000100018cd2 in testing::internal::StrStreamToString ()
#13 0x0000000100018e53 in testing::internal::BoolFromGTestEnv ()
#14 0x000000010001933e in testing::internal::Int32FromGTestEnv ()
#15 0x00007fff5fc0d500 in 
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE 
()
#16 0x00007fff5fc0bcec in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#17 0x00007fff5fc0bc9d in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#18 0x00007fff5fc0bda6 in 
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#19 0x00007fff5fc0210e in __dyld__ZN4dyld24initializeMainExecutableEv ()
#20 0x00007fff5fc06981 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#21 0x00007fff5fc016d2 in 
__dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#22 0x00007fff5fc01052 in __dyld__dyld_start ()

The gtest code for the framework included in the svn repository doesn't exhibit 
these problems because it 
links the static binaries *and* the framework, so the framework code doesn't 
actually get called at runtime.

Original comment by robdotso...@gmail.com on 31 Aug 2009 at 7:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Preston and robdotson, when you have time, could you check if the problem still
exists in the SVN　head revision?  Thanks.

Original comment by zhanyong...@gmail.com on 3 Sep 2009 at 6:23

• Changed state: Accepted
• Added labels: OpSys-OSX

[GoogleCodeExporter]

robdotson,

I just successfully built a test with gtest.framework (no static libraries) 
from scratch on Snow Leopard. I am 
using source from the trunk, not the 1.3.0 branch. 

Can you try building the trunk and following the installation instructions in 
the README. Let me know if it still 
not working and we'll track down the problem.

Preston

Original comment by preston....@gmail.com on 3 Sep 2009 at 3:00

[GoogleCodeExporter]

I've isolated the problem thus:

I am able to build both the gtest.framework and the gtest static library on 
snow leopard with out problems. 
However, there are some strange linker errors I think due to how the libstdc++ 
library is linked in.

If I create a test case that ONLY links in the gtest framework, the tests run 
flawlessly. However, when I link in 
any additional c++ libraries, libxml++ or my own libraries for example, I 
suddenly get all kinds of collisions 
with the standard library linkages.

The most obvious problem seems to be the redefinition of the operator new() 
function that is used by the 
string stream classes and functions. The versions that are linked in the other 
libraries work fine, but on 10.6 
the redefined stringstream (search for ss_) cause the errors consistently.

With 10.6's unit testing classes, as well as with other C++ unit testing 
libraries like CppTest that don't have 
these helper functions or redefinitions of operator new(), the collisions and 
calls to free() do not occur.

I've isolated the problem to the following code segment:

#if GTEST_OS_SYMBIAN
 // Streams a value (either a pointer or not) to this object.
 template <typename T>
 inline Message& operator <<(const T& value) {
   StreamHelper(typename internal::is_pointer<T>::type(), value);
   return *this;
 }
#else
 // Streams a non-pointer value to this object.
 template <typename T>
 inline Message& operator <<(const T& val) {
   ::GTestStreamToHelper(ss_, val);
   return *this;
 }

 // Streams a pointer value to this object.
 //
 // This function is an overload of the previous one.  When you
 // stream a pointer to a Message, this definition will be used as it
 // is more specialized.  (The C++ Standard, section
 // [temp.func.order].)  If you stream a non-pointer, then the
 // previous definition will be used.
 //
 // The reason for this overload is that streaming a NULL pointer to
 // ostream is undefined behavior.  Depending on the compiler, you
 // may get "0", "(nil)", "(null)", or an access violation.  To
 // ensure consistent result across compilers, we always treat NULL
 // as "(null)".
 template <typename T>
 inline Message& operator <<(T* const& pointer) {  // NOLINT
   if (pointer == NULL) {
     *ss_ << "(null)";
   } else {
     ::GTestStreamToHelper(ss_, pointer);
   }
   return *this;
 }
#endif  // GTEST_OS_SYMBIAN

after running the debugger in several stages, enabling GuardMalloc and 
malloc_error_break, implementations 
of operator<< and GTestStream*() cause stdc++'s std::basic_string<char 
*>::~basic_string() to error when 
the destructor is called, because the embedded call to free() is being called 
on a null pointer. For some 
reason, the char buffer goes out of scope during the operator<< call 
unexpectedly.

Using operator<< to print normal strings (encapsulated in ""'s) works just 
fine, but piping Message to 
operator<< consistently causes an error in code which is linked to stdc++ in 
two places.

Can you think of something that could cause that? It seems quite strange.

Also, I notice by performing 'nm gtest' and 'nm <testprog>' and 'nm 
<mylibrary>' the mangled names of the 
linked template code is quite different. I would think that the names would be 
mangled in the same way for 
methods with the same signature and linked from the same library, but they are 
quite different, which is why 
my code which calls functions in gtest get different versions of basic_string's 
destructor.

Original comment by robdotso...@gmail.com on 3 Sep 2009 at 3:50

[GoogleCodeExporter]

Thanks for doing so much work to isolate the problem! I'll take a look at this 
info and try to reproduce the 
problem.

Preston

Original comment by preston....@gmail.com on 4 Sep 2009 at 1:48

[GoogleCodeExporter]

robdotson,

I cannot reproduce this error. I've created a simple project with a C++ library 
and added the gtest.framework 
created by the Xcode project. It works. I've built the dylib using the 
configure/make and it works. Can you send 
me a copy of the simplest test code that fails for you?

Preston

Original comment by preston....@gmail.com on 15 Sep 2009 at 8:05

[GoogleCodeExporter]

Sorry to barge in on this, but I want to mention that I have an open-source 
project I compiled long ago under Mac OSX which 
crashes with the same error since upgrading to 10.6 (and still under 10.6.1).

The program produces errors like:

*** error for object 0x100xxx: pointer being freed was not allocated *** set a 
breakpoint in malloc_error_break to debug 

where xxx is the number of some object.

I recompiled the code and got the same problem.

I note that if you do a search using the Google for "pointer being freed was 
not allocated snow leopard", you will find other 
people having the same problem. Notably with Photoshop during saves. Indeed, I 
found your discussion during my search. I've 
been looking at your discussion hoping to find an answer as I use the program I 
was talking about for my work.

A discussion of this can be found at 
http://discussions.apple.com/message.jspa?messageID=10062029

So, perhaps the only solution if a fix from Apple?

Original comment by gibsonk...@gmail.com on 16 Sep 2009 at 3:00

[GoogleCodeExporter]

Here is the source code for the simplest test I can run, as you can see, it 
does nothing except assert that 1 == 1:

#include <iostream>
#include <gtest/gtest.h>

class SimpleTest : public ::testing::Test {};

TEST_F( SimpleTest, doNothing ) {       
    ASSERT_TRUE( 1 == 1 );
}

int main(int argc, char **argv) {
    std::cout << "Running main() from gtest_main.cc\n";

    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

When linking only to libgtest or gtest.framework, the program runs well. 
Linking to libxml++, my own library, or any others that I can find, 
fails with the following error:

foo(97247) malloc: *** error for object 0x########: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug

Here is the stack trace:

#0  0x00007fff85ddcff6 in __kill ()
#1  0x00007fff85e7e072 in abort ()
#2  0x00007fff85d95095 in free ()
#3  0x00000001000a9c99 in __gnu_cxx::new_allocator<char>::deallocate 
(this=0x7fff5fbfcd40, __p=0x7fff709d3500 "", unnamed_arg=25) 
at new_allocator.h:97
#4  0x00000001000a9d08 in std::string::_Rep::_M_destroy (this=0x7fff709d3500, 
__a=@0x7fff5fbfcdc0) at basic_string.tcc:431
#5  0x00000001000aa146 in std::string::_Rep::_M_dispose (this=0x7fff709d3500, 
__a=@0x7fff5fbfcdc0) at basic_string.h:238
#6  0x00000001000aa197 in std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >::~basic_string (this=0x7fff5fbfce98) at 
basic_string.h:493
#7  0x00000001000bc532 in std::basic_stringbuf<char, std::char_traits<char>, 
std::allocator<char> >::overflow (this=0x100200098, 
__c=103) at sstream.tcc:125
#8  0x00000001000ba1cf in std::basic_streambuf<char, std::char_traits<char> 
>::xsputn (this=0x100200098, __s=0x100042a24 "gtest_", 
__n=6) at streambuf.tcc:102
#9  0x00007fff84d3aae4 in std::__ostream_write<char, std::char_traits<char> > ()
#10 0x00007fff84d38b98 in std::__ostream_insert<char, std::char_traits<char> > 
()
#11 0x00007fff84d38c58 in std::operator<< <std::char_traits<char> > ()
#12 0x000000010000e2d9 in GTestStreamToHelper<char [7]> ()
#13 0x000000010000e338 in testing::Message::operator<< <char [7]> ()
#14 0x000000010000cc93 in testing::internal::FlagToEnvVar ()
#15 0x000000010000cf8f in testing::internal::BoolFromGTestEnv ()
#16 0x000000010000d9c2 in __static_initialization_and_destruction_0 ()
#17 0x000000010000d937 in global constructors keyed to 
_ZNSt3tr112_GLOBAL__N_16ignoreE ()
#18 0x00007fff5fc0d500 in 
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE 
()
#19 0x00007fff5fc0bcec in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#20 0x00007fff5fc0bc9d in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#21 0x00007fff5fc0bda6 in 
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#22 0x00007fff5fc0210e in __dyld__ZN4dyld24initializeMainExecutableEv ()
#23 0x00007fff5fc06981 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#24 0x00007fff5fc016d2 in 
__dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#25 0x00007fff5fc01052 in __dyld__dyld_start ()

I think the problem starts at line 12. At this point Message::operator<< 
creates a new char buffer of length 7 from the char pointer passed 
from GTestStreamToHelper(), presumably to print out "gtest_\0". The buffer is 
passed to std::ostream all the way through line 8, at which 
point an attempt to create a basic::string object fails with a buffer overflow 
in line 7. Since the string isn't actually created, the destructor fails 
when trying to free() up the memory, abort()ing the program on x86_64, but 
continues to run (but throw the error) on x86 & ppc.

Original comment by robdotso...@gmail.com on 16 Sep 2009 at 4:19

[GoogleCodeExporter]

When I run the code on x86, it runs with the following output:

foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
Running main() from gtest_main.cc
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from SimpleTest
[ RUN      ] SimpleTest.doNothing
[       OK ] SimpleTest.doNothingfoo(97272) malloc: *** error for object 
0xa0858db0: pointer being freed was 
not allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
 (0 ms)
[----------] foo(97272) malloc: *** error for object 0xa0858db0: pointer being 
freed was not allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
1 test from SimpleTest (0 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran.foo(97272) malloc: *** error for 
object 0xa0858db0: pointer 
being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
foo(97272) malloc: *** error for object 0xa0858db0: pointer being freed was not 
allocated
*** set a breakpoint in malloc_error_break to debug
 (1 ms total)
[  PASSED  ] 1 test.

From the previous comment, the __static_initialization_and_destruction_0 
function, which must create static 
strings for use during the tests creates 50+ objects (unnecessarily?) when the 
gtest.framework is loaded, 
which can probably be avoided.

After that, strings are printed normally, (the [==========] lines), but fails 
again when a string is made 
from a number, specifically when it is time to display the timing in 
milliseconds, which makes me think that 
the XXXXlFromGTestEnv() functions are using Message in a weird way.

Why doesn't gtest just use std::string and std::wstring natively with 
std::ostream? Why is there a bridge class 
at all?

Original comment by robdotso...@gmail.com on 16 Sep 2009 at 4:25

[GoogleCodeExporter]

Also, notice that each time, it is the object at the *same* memory location 
that fails to be allocated and freed.

Original comment by robdotso...@gmail.com on 16 Sep 2009 at 4:26

[GoogleCodeExporter]

As a note to gibsonkerr, the Photoshop error is not the same. The photoshop 
error is:

Non-aligned pointer being freed (2)

which means one of the linked libraries (probably a plugin) is not aligning 
it's allocated memory to a word 
boundary, but photoshop (or stdc++) expects it to be when delete() is called. 
That's either due to different 
compilers being used to create the plugin and photoshop, or just sloppy 
intrinsics on the programmer's part.

Original comment by robdotso...@gmail.com on 16 Sep 2009 at 4:31

[GoogleCodeExporter]

To follow up on two fronts:

I was able to replicate the Photoshop problem, which is due to a bug in the 
Gaussian Blur filter. Sometimes 
the memory isn't correctly aligned, throwing the first error, and *shifting* 
(??!) the memory address, which is 
then deallocated, which fails.

On the WebKit tip, I found this in the trac source:

void FastMallocZone::zoneFree(malloc_zone_t*, void* ptr)
4270    {
4271        // Due to <rdar://problem/5671357> zoneFree may be called by the 
system free even if the 
pointer
4272        // is not in this zone.  When this happens, the pointer being freed 
was not allocated by any
4273        // zone so we need to print a useful error for the application 
developer.
4274        malloc_printf("*** error for object %p: pointer being freed was not 
allocated\n", ptr);
4275    }

Unfortunately, I don't have radar access, so I can't see the text of this bug, 
workarounds or anything else. But 
it appears that operator new() doesn't use a valid zone when calling it's 
malloc() function. My understanding is 
that malloc(sizeof(foo)) calls malloc_zone_malloc(malloc_default_zone(), 
sizeof(foo)). Either operator new is 
calling malloc_zone_malloc directly with NULL or an invalid address for the 
desired zone, or 
malloc_default_zone() is returning different values for different libraries. 
Either way, the problem is even more 
troubling than I thought.

Original comment by robdotso...@gmail.com on 16 Sep 2009 at 4:49

[GoogleCodeExporter]

Sorry to bomb this thread with comments.

Running again with GuardMalloc on (linking to libgmalloc) dies with the 
following ouput:

GuardMalloc: GuardMalloc version 18
GuardMalloc[foo-97346]: guard malloc zone failure: freeing a pointer we didn't 
allocate that was not claimed by any registered 
zone
GuardMalloc[foo-97346]: Explicitly trapping into debugger!!!

The backtrace:

#0  0x0000bbd9 in guard_malloc_zone_failure ()
#1  0x0000c7f1 in GMfree ()
#2  0x000a7163 in __gnu_cxx::new_allocator<char>::deallocate (this=0xbfffce68, 
__p=0xa0858db0 "", unnamed_arg=13) at 
new_allocator.h:97
#3  0x000a71c2 in std::string::_Rep::_M_destroy (this=0xa0858db0, 
__a=@0xbfffcec0) at basic_string.tcc:431
#4  0x000a75a0 in std::string::_Rep::_M_dispose (this=0xa0858db0, 
__a=@0xbfffcec0) at basic_string.h:238
#5  0x000a75f4 in std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >::~basic_string (this=0xbfffcf40) at 
basic_string.h:493
#6  0x000b72bc in std::basic_stringbuf<char, std::char_traits<char>, 
std::allocator<char> >::overflow (this=0xb0088f4c, 
__c=103) at sstream.tcc:125
#7  0x000b543d in std::basic_streambuf<char, std::char_traits<char> >::xsputn 
(this=0xb0088f4c, __s=0x47d14 "gtest_", 
__n=6) at streambuf.tcc:102
#8  0x96a6718c in std::__ostream_write<char, std::char_traits<char> > ()
#9  0x96a65208 in std::__ostream_insert<char, std::char_traits<char> > ()
#10 0x96a652bc in std::operator<< <std::char_traits<char> > ()
#11 0x0001acf4 in GTestStreamToHelper<char [7]> ()
#12 0x0001ad42 in testing::Message::operator<< <char [7]> ()
#13 0x00019995 in testing::internal::FlagToEnvVar ()
#14 0x00019c35 in testing::internal::BoolFromGTestEnv ()
#15 0x0001a458 in __static_initialization_and_destruction_0 ()
...snip...

So the zone is being discarded or destroyed, but *only* when the 
Message::operator<< initiates string output while linked to 
another c++ library, so something in it's implementation is losing track of the 
pointer. This doesn't happen when *other* c++ 
libraries are linked together, only this one.

Original comment by robdotso...@gmail.com on 16 Sep 2009 at 5:05

[GoogleCodeExporter]

The only way I've found to avoid this problem is to strip *all* classes and 
methods that need std::string objects 
out of my library. A really horrible workaround, but that's the only thing I 
could do.

Original comment by writeyou...@gmail.com on 24 Sep 2009 at 6:42

[GoogleCodeExporter]

Still searching for people with the same issue. This site:

http://www.cocoabuilder.com/archive/message/cocoa/2009/9/17/245285

Says there is a problem in that basic_string.h has 
_GLIBCXX_FULLY_DYNAMIC_STRING set, and it must also be set 
in any code compiled for Mac using c++.  Not sure if this is related. I 
personally tried it and my compiled code still 
had the same issues.

Could it be that there are other compiler flags that need set when compiling 
using libstdc++.6.dylib or am I 
barking up the wrong tree here?

Original comment by gibsonk...@gmail.com on 27 Sep 2009 at 1:15

[GoogleCodeExporter]

You're barking up the right tree.  As a C++ developer on Snow Leopard, and I 
can tell you that I'm getting bitten 
by this dynamic string bug left and right.  All you need to do to confirm it is 
to look at the string object that's 
being freed.  So, some library has fully dynamic string set (and the standard 
C++ library does), and another 
doesn't.

Original comment by jwieg...@gmail.com on 30 Oct 2009 at 3:05

[GoogleCodeExporter]

Ok then, that means that my library must be the one with static strings... I've 
only got gtest, my lib & stdc++. 
How can I tell or force my library to use all dynamic strings? To solve this on 
OSX I wrote a wrapper class for 
CFString to get rid of all references to std::string... But this isn't really 
an option for linux, and I'd rather not have 
two divergent code bases.

Original comment by robdotso...@gmail.com on 30 Oct 2009 at 3:39

[GoogleCodeExporter]

BTW, I've tried passing _GLIBCXX_FULLY_DYNAMIC_STRING to both gtest and my own 
libraries to no avail.

Original comment by robdotso...@gmail.com on 30 Oct 2009 at 3:42

[GoogleCodeExporter]

I am having the same problem.  The code that is the problem for me uses getline 
to take data from a file stream 
and put it into a string, like this getline(filestream, string).  However, 
after I started having this problem I 
switched and compiled my code using g++ with Terminal and it worked fine.  Then 
I went back to XCode and 
changed my Active Configuration from Debug to Release and it started working!
Not sure if this will help anyone out, but I thought I would share it.

Original comment by ks81...@gmail.com on 24 Nov 2009 at 3:28

[GoogleCodeExporter]

I personally use the Google Testing Framework on a very large software project 
without any problems. My efforts 
to recreate the issue in a small application have not been fruitful. What would 
really help me trace down this 
issue would be a small snippet of code (linking only to the libraries included 
on Mac OS X) that exhibits this 
behavior. With the issue in hand, I should be able to make the necessary 
changes fairly quickly.

Original comment by preston....@gmail.com on 24 Nov 2009 at 9:08

[GoogleCodeExporter]

Original comment by w...@google.com on 26 Feb 2010 at 8:02

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This doesn't appear to be a gtest bug.

Original comment by w...@google.com on 6 Mar 2010 at 6:11

• Changed state: WontFix

[GoogleCodeExporter]

Issue 264 has been merged into this issue.

Original comment by w...@google.com on 25 Mar 2010 at 6:29

[GoogleCodeExporter]

Is there a workaround or a better explanation for the won't fix status?

Original comment by PaulSolt on 30 Mar 2010 at 11:31

[GoogleCodeExporter]

Also getting the same on OSX(x86_64)

TEST(Test, foo)
{   
    ASSERT_EQ(1, 1);    
}

int main (int argc, char **argv) {

    ::testing::InitGoogleMock(&argc, argv);

    return RUN_ALL_TESTS();
}

If I leave TEST as empty then program runs without error. But of course does 
nothing.

Error:

gmock-trial(64005) malloc: *** error for object 0x7fff71062500: pointer being 
freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Original comment by matti.r...@gmail.com on 12 Apr 2010 at 8:26

[GoogleCodeExporter]

Ok, seems not to be gtest issue.

Issue is in 10.6 OSX. See 
http://discussions.apple.com/thread.jspa?messageID=10244508

In xCode removing all preprosessor macros from active target settings fixed the 
issue.

Original comment by matti.r...@gmail.com on 13 Apr 2010 at 7:40

[GoogleCodeExporter]

possible solution: add -fPIC in gcc g++ line for the actual linking of the 
executable.

I found this worked for me, on a totally different library, but same error 
message.

Original comment by msherbo...@gmail.com on 10 Dec 2010 at 12:22

[GoogleCodeExporter]

I'm no longer getting a similar issue (Merged Issue 264) with the latest 10.6.5 
OS X (10H574) and Gtest (1.5). I did switch computers from a 2007 Macbook Pro 
3,1 to a 2010 MBP (6,2)

I used to get the error all the time when I returned a std::vector<std::string> 
from any of my classes to a Google Test case.

Original comment by PaulSolt on 10 Dec 2010 at 1:35

[GoogleCodeExporter]

This issue is still occurring on OS X 10.6.5 and GTest 1.5. The link about the 
10.6 OS X issue didn't help (preprocessor macros are empty). "in gcc g++" isn't 
clear, but if that means "Other Linker Flags" then it doesn't help. Also tried 
removing any other libraries besides libgtest_main and libgtest (tried static, 
dynamic, AND framework.)

The issue occurs any time the libraries are included, and does not occur when 
they are not included. The sample app runs perfectly, but does not involve 
XCode.

Original comment by theprope...@gtempaccount.com on 13 Jan 2011 at 10:35