-
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!
-
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
-
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.
-
I said when you build SFML, not when you link it. Meaning you take the SFML source code and build OS X SFML binaries.
-
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)
-
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. :D
-
perfect, sounds good to me! bring in the calvary!
-
Yeah, well... don't expect too much from me. :P
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 (http://sscce.org/).
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;
}
-
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. :P
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 (http://sscce.org/).
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
-
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.
-
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.
-
I'm sorry to say, but without a sscce I can't help you more as I'm not able to reproduce this.
-
kk, I can get you one tonight and send you a github link if you like?
-
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.
-
hey no worries! Ill post a snippet for everyone. I should have it up tonight or maybe tomorrow, but no rush!
-
Ok, here we go. I figured that since my issue only occurred when the destructor was called, that perhaps the original example in #5 wasn't working because of the main scope.
So here we go, this is the simplest way to recreate the error:
#include <SFML/System.hpp>
#include <SFML/Graphics.hpp>
void test();
int main()
{
test();
return 0;
}
void test()
{
sf::String s;
sf::Text t;
}
test(8044,0x7fff786ce000) malloc: *** error for object 0x7fff5a3c1a00: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
thats not all folks, another interesting thing is if i comment out the the string line, it appears to get caught in some sort of infinite loop as the program never ends:
#include <SFML/System.hpp>
#include <SFML/Graphics.hpp>
void test();
int main()
{
test();
return 0;
}
void test()
{
//sf::String s;
sf::Text t;
}
however, comment out the text and only have String, and everything ends up working fine:
#include <SFML/System.hpp>
#include <SFML/Graphics.hpp>
void test();
int main()
{
test();
return 0;
}
void test()
{
sf::String s;
//sf::Text t;
}
Process finished with exit code 0
Just for fun, because I noticed the original error trace mentioned the VertexArray, I went ahead and threw that in there, but it didn't seem to have any affect on the results.
anyway, let me know what you think :)
-
Ok, I'll try to have a look at that this weekend.
-
I'm betting you're using libstdc++ and not libc++. The former's been deprecated on OS X for a while now. Try libc++ instead.
BTW
However, if your project depends on libstdc++ (directly or indirectly), you need to build SFML yourself and configure your project accordingly.
HTH
-
I am using libc++.
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 -std=c++14 -stdlib=libc++")
I tried to mirror everything from Xcode
-
Hum.. Okay. Could you post the CMake project file as well?
-
#CMake Version
cmake_minimum_required(VERSION 3.5)
# Enable debug symbols by default
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build(Debug or Release)" FORCE)
endif()
project(Project)
if (WIN32)
#do something
endif (WIN32)
if (UNIX)
#do something
endif (UNIX)
if (MSVC)
#do something
endif (MSVC)
# CMake Options
if(APPLE)
add_definitions(-D_GLIBCXX_FULLY_DYNAMIC_STRING)
endif(APPLE)
add_compile_options(-D_GLIBCXX_FULLY_DYNAMIC_STRING=1)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 -std=c++14 -stdlib=libc++")
# Set version information in a config.h file
set(myproject_VERSION_MAJOR 1)
set(myproject_VERSION_MINOR 0)
configure_file(
"src/Resources/config.h.in"
"${PROJECT_BINARY_DIR}/config.h"
)
include_directories("${PROJECT_BINARY_DIR}")
# Define sources and executable
set(EXECUTABLE_NAME "Project")
# Include Project Files
include_directories("src")
include_directories("doc")
include_directories("lib")
include_directories("tests")
set(SOURCES src/main.cpp src/GameStates/BaseState.h src/Managers/EventManager.cpp src/Managers/EventManager.h src/Game/Game.h src/Game/Game.cpp src/Managers/ResourceManager.h
src/Managers/SharedContext.h src/GameStates/StateGame.cpp src/GameStates/StateGame.h src/GameStates/StateIntro.cpp src/GameStates/StateIntro.h
src/GameStates/StateMainMenu.cpp src/GameStates/StateMainMenu.h src/Managers/StateManager.cpp src/Managers/StateManager.h src/GameStates/StatePaused.cpp src/GameStates/StatePaused.h
src/Utilities/Utilities.h src/Window/Window.cpp src/Window/Window.h src/Resources/Fonts/arial.ttf src/Resources/Configs/keys.cfg src/Resources/Textures/intro.png
src/Resources/Textures/icon.png src/Resources/Spritesheets/Mushroom.png src/Managers/TextureManager.h src/Utilities/easylogging++.h src/Graphics/SpriteSheet.cpp src/Graphics/SpriteSheet.h
src/Graphics/Directions.h src/Graphics/AnimBase.cpp src/Graphics/AnimBase.h src/Graphics/AnimDirectional.cpp src/Graphics/AnimDirectional.h src/Entities/EntityBase.cpp src/Entities/EntityBase.h
src/Managers/EntityManager.cpp src/Managers/EntityManager.h src/Entities/Enemy.cpp src/Entities/Enemy.h src/Entities/Player.cpp src/Entities/Player.h src/Entities/Character.cpp
src/Entities/Character.h src/Graphics/Map.cpp src/Graphics/Map.h src/Graphics/DebugOverlay.h src/Utilities/Logger.cpp src/Utilities/Logger.h src/Resources)
add_executable(${EXECUTABLE_NAME} ${SOURCES})
# Detect and add SFML
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake_modules")
#See the FindSFML.cmake file for additional details and instructions
find_package(SFML REQUIRED system window graphics network audio)
if(SFML_FOUND)
include_directories(${SFML_INCLUDE_DIR})
target_link_libraries(${EXECUTABLE_NAME} ${SFML_LIBRARIES})
endif()
-
I tested again with your CMakeLists.txt (I just kept main.cpp from the source file, but that's the only change I've done), but couldn't reproduce the issue... Removing -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 didn't change anything for me.
Now, maybe there's something fishy going on when configuring the cmake project, either with your IDE or your global environment. Try adding set(CMAKE_VERBOSE_MAKEFILE TRUE) and post the compilation commands from the two systems you have.
-
Interesting. I will try that tonight.
-
hey im back. Sorry for the late notice, got really busy with work. Anyway, I am still having this problem unfortunately. I started a new project just to see where I can get, and when I close the window, this same issue occurs.
-
I am not entirely sure what you mean by the complication commands. Are you looking for the cmake logs or the IDE messages?
I set the verbose makerfile to true, here is my console out:
Example(24764,0x7fff770bc000) malloc: *** error for object 0x7fff4ff5bb00: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Process finished with exit code 6
here is the cmake output:
/Applications/CLion.app/Contents/bin/cmake/bin/cmake -DCMAKE_BUILD_TYPE= -G "CodeBlocks - Unix Makefiles" /Users/name/ClionProjects/Example
-- Found SFML .. in /Library/Frameworks/SFML.framework
SFML has been found
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/name/ClionProjects/Example/cmake-build-default
here is the ide output:
/Applications/CLion.app/Contents/bin/cmake/bin/cmake --build /Users/name/ClionProjects/Example/cmake-build-default --target Example -- -j 4
/Applications/CLion.app/Contents/bin/cmake/bin/cmake -H/Users/name/ClionProjects/Example -B/Users/name/ClionProjects/Example/cmake-build-default --check-build-system CMakeFiles/Makefile.cmake 0
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 Example
/Applications/CLion.app/Contents/bin/cmake/bin/cmake -H/Users/name/ClionProjects/Example -B/Users/name/ClionProjects/Example/cmake-build-default --check-build-system CMakeFiles/Makefile.cmake 0
/Applications/CLion.app/Contents/bin/cmake/bin/cmake -E cmake_progress_start /Users/name/ClionProjects/Example/cmake-build-default/CMakeFiles 3
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Makefile2 CMakeFiles/Example.dir/all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Example.dir/build.make CMakeFiles/Example.dir/depend
cd /Users/name/ClionProjects/Example/cmake-build-default && /Applications/CLion.app/Contents/bin/cmake/bin/cmake -E cmake_depends "Unix Makefiles" /Users/name/ClionProjects/Example /Users/name/ClionProjects/Example /Users/name/ClionProjects/Example/cmake-build-default /Users/name/ClionProjects/Example/cmake-build-default /Users/name/ClionProjects/Example/cmake-build-default/CMakeFiles/Example.dir/DependInfo.cmake --color=
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/Example.dir/build.make CMakeFiles/Example.dir/build
make[3]: Nothing to be done for `CMakeFiles/Example.dir/build'.
[100%] Built target Example
/Applications/CLion.app/Contents/bin/cmake/bin/cmake -E cmake_progress_start /Users/name/ClionProjects/Example/cmake-build-default/CMakeFiles 0
and let me know if you want any of the cmake-build logs.
I tested again with your CMakeLists.txt (I just kept main.cpp from the source file, but that's the only change I've done), but couldn't reproduce the issue... Removing -D_GLIBCXX_FULLY_DYNAMIC_STRING=1 didn't change anything for me.
Now, maybe there's something fishy going on when configuring the cmake project, either with your IDE or your global environment. Try adding set(CMAKE_VERBOSE_MAKEFILE TRUE) and post the compilation commands from the two systems you have.
-
make[3]: Nothing to be done for `CMakeFiles/Example.dir/build'.
The interesting bit is missing, try a clean before building.
and let me know if you want any of the cmake-build logs.
At this point, why not.
-
Ok, I solved it!!!!
Ok, so I started reading through the logs before I was going to post them and discovered a few things.
First of all,
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")
is keeping the default flags, which was -std=gnu++14, so I went ahead and change it to not include the previously set flags. This solved the problem with the SSCCE, however I STILL had the problem in the actual program. As I started reading through THOSE logs, I noticed that they were reading SFML 2.3.x versions from the Framework that were somehow leftover, despite having all the recent version of the dylibs.
I deleted all the framework files and re-re-re-downloaded SFML manually and manually mv-ing them into their respective locations.
Anyway, you guys have been absolutely amazing and responsive. Sorry that this ended up being just a dumb environment issue. Hopefully this will help someone else in the future if they run into the same problem.
-
That's an unusual good news for a Monday morning! ;D