std::basic_string crash

[mantognini]

Crash with malloc: *** error for object 0x...: pointer being freed was not allocated

See http://www.sfml-dev.org/forum-fr/viewtopic.php?p=30752#30752 (french) for more details (and potential solutions).

(Bug reported to Apple on 10 February 2011)

Here is a MCRP as of adca580 :

#include <SFML/System.hpp> 
int main() 
{ 
    sf::String s; 
    return 0; 
} 

and the backtrace (OS X 10.7.2, GCC or Clang from Xcode 4.2.1) :

(gdb) backtrace
#0  0x00007fff8d51982a in __kill ()
#1  0x00007fff91cada9c in abort ()
#2  0x00007fff91d0c84c in free ()
#3  0x00000001000019dd in __gnu_cxx::new_allocator<char>::deallocate (this=0x7fff5fbff8a0, __p=0x10000a2b0 "") at new_allocator.h:97
#4  0x0000000100001938 in std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_Rep::_M_destroy (this=0x10000a2b0, __a=@0x7fff5fbff910) at basic_string.tcc:430
#5  0x0000000100001789 in std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_Rep::_M_dispose (this=0x10000a2b0, __a=@0x7fff5fbff910) at basic_string.h:237
#6  0x00000001000016a0 in std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::~basic_string (this=0x7fff5fbff9b0) at basic_string.h:492
#7  0x0000000100001655 in std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::~basic_string (this=0x7fff5fbff9b0) at basic_string.h:492
#8  0x0000000100001635 in sf::String::~String (this=0x7fff5fbff9b0) at String.hpp:43
#9  0x0000000100001615 in sf::String::~String (this=0x7fff5fbff9b0) at String.hpp:43
#10 0x0000000100001546 in main () at /Users/marcoantognini/Prog/Cpp/Test/SFML/test/test/main.cpp:7

Current workaround :
Add -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 to CMAKE_CXX_FLAGS.

This solution is not officially implemented because I don't know the potential drawbacks.

[mantognini]

Finally got an answer from some Apple dev. They apparently don't want to fix this issue on their side. They gave me three workarounds :

• Use extern template class std::basic_string<int>; in String.cpp and add template class std::basic_string<int>; in ALL C++ source that uses sf::String. Clearly not feasible, of course.
• Use clang with its new std lib ( -stdlib=libc++ compiler option ). This is available only on Mac OS X 10.7+ thus this is not suitable for SFML.
• Use std::vector instead of std::basic_string and manually manage trailing \0.

The last solution is the better but still I don't like it : modifying a part of SFML that work on other OSes to make it work on Mac is not a solution.

From this perspective I guess the above workaround with _GLIBCXX_FULLY_DYNAMIC_STRING macro is the only solution that I know of at this moment.

[mjbshaw]

Out of curiosity, why would the first option not be feasible? template class std::basic_string<int>; could just be put in String.hpp, could it not?

[mantognini]

Good question. I didn't remember so I did the modification to test. Here is the diff.

The problem is, apparently, it creates duplicate symbols with predefined templates.

[dansgithubuser]

I didn't compile SFML from source, and I wanted a different way to size text in any case. The easiest thing for me was to create an sf::Text alternative myself, copying from Text.hpp and Text.cpp and using something other than sf::String.

[mantognini]

using something other than sf::String.

but you know that this issue is directly related to the underlying std::basic_string, right?

[eXpl0it3r]

Of course it's not nice to keep things around that can possible crash an application, but I wonder whether it's a library's job to implement workarounds for broken STL implementations, especially if it's only for a specific and older version.

On the other hand if it's just a simple version check and flag setting in CMake, I don't see a reason not to implement it and reading a bit more (e.g. here) about that flag it seems common practice to do so.

The question is of course, whether there's still someone around with that old system setup who can test a possible implemented fix. . 😉

[LaurentGomila]

Marco plans to drop support for OS X 10.5 and 10.6 in a near future. I guess that will solve this problem.

[mantognini]

Unfortunately, it is still present on 10.7/8 since gcc is still available on those OSes. But I guess implementing the fix as @eXpl0it3r suggested should not harm anyone.

[mjbshaw]

But GCC has been removed since Xcode 4.2...

[mantognini]

Right! They replaced it with llvm-gcc. So it should be safe to close this issue now without a fix.