malloc: *** error for object 0x7fa16b8d6f60: pointer being freed was not allocat

[tramstheman]

Ok, so first of all I have tried this:
https://github.com/SFML/SFML/issues/5

I don't think this is the issue however, after following the breakpoint, this happens after one of my gamestates (the intro state)'s destructor is called. As it progresses it calls:

sf::Text::~Text()
sf::Text::~Text()
sf::VertexArray::~VertexArray()
sf::VertexArray::~VertexArray()

and then breaks ...

inline _LIBCPP_INLINE_VISIBILITY void __deallocate(void *__ptr) {
#ifdef _LIBCPP_HAS_NO_BUILTIN_OPERATOR_NEW_DELETE
  ::operator delete(__ptr);
#else
  __builtin_operator_delete(__ptr); <<< RIGHT HERE!!!
#endif
}

This is my output:

Project(33063,0x7fff72aef000) malloc: *** error for object 0x7fa16b8d6f60: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

 

Here is the relevant line in my cmake file:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 -std=c++14 -stdlib=libc++")

so I think im doing everything right from the apple standpoint.

OSX: 10.11.5
CMAKE: VERSION 3.5
SFML Version: 2.3

IDE: CLION

Let me know if there is any other information I can give you. The funny thing is, this works fine when I run it in Xcode, but I don't really want to use Xcode for this project. Thanks in advance everyone!

[eXpl0it3r]

What's the call stack? What compiler version are you using?
I'm not 100% certain, but from the linked issue I interpret that the compiler flag needs to be set when compiling SFML itself

[tramstheman]

using LLVM.

i have this in my cmake:

if(SFML_FOUND)
    include_directories(${SFML_INCLUDE_DIR})
    target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
endif()

is this where you think I should add the flags? Would it be possible to get an example of how it would look, I am still new to CMake.

[eXpl0it3r]

I said when you build SFML, not when you link it. Meaning you take the SFML source code and build OS X SFML binaries.

[tramstheman]

Interesting. Assuming that this solution works (I will try it later), why would everyone work fine in xcode but require this flag when compiling with cmake? Another interesting turn of events is that everything works fine when I run it on my mac laptop with the same OS/SFML version/CLION Version/CMAKE, etc. (much newer laptop though)

[eXpl0it3r]

Ah I didn't see that it works fine through XCode. I'm not an OS X user, so no idea really. Let's summon our OS X dev.

[tramstheman]

perfect, sounds good to me! bring in the calvary!

[Hiura]

Yeah, well... don't expect too much from me. 


I had a look at #5 and it's related discussions, and to be honest it's all a bit confusing. I guess the root cause is a "bad" setup which involves a buggy STL implementation. And if it's something else than #5, know that memory corruption are tough bugs! Sometimes the crash happens in a different location than where the bug actually is. In such cases, it helps a lot to extract a sscce.

Since you have access to two different machines, although with similar setup, I'm wondering if CLion is confused by an old compiler lurking around somewhere. Here a few things you could try and that could help us identify the underlying issue:

• generally speaking, make sure that your software is up-to-date; e.g. there is a security update for your OS I believe; also check that Xcode is up-to-date in case CLion uses its compilers. Same for CLion if possible. And why not update SFML to 2.4.0 as well. 
• run cmake from the command line instead of CLion and see if it detects another compiler or if the crash still happens
• identify the exact version of the compiler used by CLion: look for CMAKE_CXX_COMPILER in the "Cache" tab of the "CMake" panel from CLion. Then, in the terminal run `<path/to/the/compiler> --version` for example.
• if you're lucky, maybe CLion is simply not properly configured.
• with all that, you can also try to see if there's a specific difference with the configuration of you newer Mac.

BTW, did you try running this simple piece of code:

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

[tramstheman]

Hello sorry for the late response. I was gone all weekend. I am back and ready to hash this out. I am still trying some things in this list but I wanted to let you know where I was at so far. Here you go:

Yeah, well... don't expect too much from me. 


I had a look at #5 and it's related discussions, and to be honest it's all a bit confusing. I guess the root cause is a "bad" setup which involves a buggy STL implementation. And if it's something else than #5, know that memory corruption are tough bugs! Sometimes the crash happens in a different location than where the bug actually is. In such cases, it helps a lot to extract a sscce.

Since you have access to two different machines, although with similar setup, I'm wondering if CLion is confused by an old compiler lurking around somewhere. Here a few things you could try and that could help us identify the underlying issue:

• generally speaking, make sure that your software is up-to-date; e.g. there is a security update for your OS I believe; also check that Xcode is up-to-date in case CLion uses its compilers. Same for CLion if possible. And why not update SFML to 2.4.0 as well. 

Performed the updates on the OS and SFML, no change in results
   

• run cmake from the command line instead of CLion and see if it detects another compiler or if the crash still happens
• identify the exact version of the compiler used by CLion: look for CMAKE_CXX_COMPILER in the "Cache" tab of the "CMake" panel from CLion. Then, in the terminal run `<path/to/the/compiler> --version` for example.

Trammels-Macintosh:bin trammelmay$ c++ --version
Apple LLVM version 8.0.0 (clang-800.0.38)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
   

• if you're lucky, maybe CLion is simply not properly configured.
• with all that, you can also try to see if there's a specific difference with the configuration of you newer Mac.

BTW, did you try running this simple piece of code:

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

This actually works fine, interestingly enough

[Hiura]

This actually works fine, interestingly enough

With that in mind and the fact that your setup seems up-to-date and okay, I'm inclined to think it has nothing to do with #5 but instead there is a nasty bug in your app... Try using debuggers/sanitizers to detect memory corruption as early as possible in the program lifetime. It could be a simple out-of-bound access somewhere... If sanitizers cannot pinpoint the source of the bug, try reducing your app to a sscce.

[tramstheman]

I have debugged the application until I found when this occurs. It happens when a game state destructor is called. More specifically, as the "Intro State" is being destructed, some of the Assets, namely Font which calls vertex array destructors and Text destructors. The Text destructor breaks when attempting to deallocate. This doesn't seem to be something I have control over though.

Launch app -> intro state -> main menu

The transition from intro to main menu is where the destructor is called on the intro state. It is pretty isolated at this point.

[Hiura]

I'm sorry to say, but without a sscce I can't help you more as I'm not able to reproduce this.

[tramstheman]

kk, I can get you one tonight and send you a github link if you like?

[Hiura]

Post here the snippet of code that reproduces the issue (with less indirection, futur users will find the solution faster if they encounter the same issue). It should really be self contained and as short as possible.

PS: I can't promise I'll be able to look at it before the weekend.

[tramstheman]

hey no worries! Ill post a snippet for everyone. I should have it up tonight or maybe tomorrow, but no rush!