OSX /w homebrew'd gcc 4.8.3, sf::String, sf::Text uninitialized null pointer bug

[cdelorme]

Experiencing malloc null pointer errors when my application ends if I declared an sf::Text or sf::String and never initialized them (or initialize with empty strings).

I did some research, and realize this is not necessarily a "new" issue:

• #5
• #384
• #389
• #510

However, the solution at that time was to update xCode or the gcc version, and this was back on OSX 10.5/10.6.

I am running OSX 10.9.3, using homebrew'd gcc/g++ 4.8.3, and sfml 2.1.  I am not using xcode or clang.  I use these commands to compile and build from a terminal:

Code: [Select]

    g++ -std=c++11 -c test.cpp
    g++ -lsfml-graphics -lsfml-window -lsfml-system -lsfml-audio -o test test.o

The code builds, but crashes when ending execution:

    #include <SFML/Graphics.hpp>

    int main() {

        sf::Text text;

        return 0;
    }
 

Also This:

    #include <SFML/Graphics.hpp>

    int main() {

        sf::String word;

        return 0;
    }
 

While knowing about this problem helps mitigate it, it's annoying to know that I have to always add code to a class constructor that has a text or string to initialize it to a non-empty-string value to avoid this problem.  Especially if the use of said sf::Text or sf::String variables is optional.

Which leaves me with two questions:

• Are we still considering this an OSX bug when it's still happening in 10.9+ while using gcc 4.8.3 built in homebrew?
• Is there any chance a patch may be reconsidered so developers don't need this edge-case knowledge?

[Jesper Juhl]

Was SFML and its dependencies built with the same compiler as you build your application with?
If not, then that is the first thing to fix.
While clang (and thus xcode) tries to be binary compatible with code built with GCC that support is still not perfect and may explain weirdness like this. Building SFML + your app with the exact same compiler is the easiest way to avoid weird issues.

[cdelorme]

@Jesper Juhl

That's an excellent point, and I will try building sources with my compiler to see if it fixes it.  I've been using the prebuilt libraries that install with the shell script.  It would totally make sense if those were built with clang, and would also clarify that it's an OSX bug.

However, this means I would like even more to see a patch submitted so that the files on the SFML website don't feature this bug and cause mishaps for developers using apple computers, forcing them to both be aware of and code around it.

I'll post again once I have tested with gcc built source.

[Hiura]

As mentioned in #5, it's not SFML fault if this happens.

One of the workaround that Apple's dev gave me is to use std::vector instead of std::basic_string and reimplement all string functions... You can understand that I won't go down that path.

If you downloaded the GCC version from the download page, it was compiled on 10.5 with gcc v<put a very old version number here> provided by Apple for this OS. And I think `_GLIBCXX_FULLY_DYNAMIC_STRING` was not defined.

You can try:

• to rebuild SFML with gcc from homebrew. It's very easy, see the cmake tutorial and remember to set the C++ and C compiler appropriately.
• if it doesn't work, try defining `_GLIBCXX_FULLY_DYNAMIC_STRING` and rebuild SFML again.

Note that I won't provide any gcc build for future version of SFML (unless Apple support it officially again but that would be a 180° turn so don't expect it). I won't provide any patch in SFML codebase for that bug either.

[cdelorme]

I read the cmake tutorial, at least a dozen times over now, and it was never clear to me.  After being thrown for a loop by the fact that cmake completely ignores shell/environment variables, I finally managed to at least get this to run:

Code: [Select]


    cmake -D CMAKE_CXX_COMPILER=$(which g++) -D CMAKE_C_COMPILER=$(which gcc) -D CMAKE_CXX_FLAGS="-std=c++11" -D CMAKE_C_FLAGS="-std=c++11" -D CMAKE_OSX_ARCHITECTURES="x86_64" .

    -- The C compiler identification is GNU 4.8.3
    -- The CXX compiler identification is GNU 4.8.3
    -- Checking whether C compiler has -isysroot
    -- Checking whether C compiler has -isysroot - yes
    -- Checking whether C compiler supports OSX deployment target flag
    -- Checking whether C compiler supports OSX deployment target flag - yes
    -- Check for working C compiler: /usr/local/bin/gcc
    -- Check for working C compiler: /usr/local/bin/gcc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Checking whether CXX compiler has -isysroot
    -- Checking whether CXX compiler has -isysroot - yes
    -- Checking whether CXX compiler supports OSX deployment target flag
    -- Checking whether CXX compiler supports OSX deployment target flag - yes
    -- Check for working CXX compiler: /usr/local/bin/g++
    -- Check for working CXX compiler: /usr/local/bin/g++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Found OpenGL: /System/Library/Frameworks/OpenGL.framework
    -- Found Freetype: /Users/cdelorme/Documents/packages/tmp/SFML-2.1/extlibs/libs-osx/Frameworks/freetype.framework (found version "2.4.11")
    -- Found GLEW: /Users/cdelorme/Documents/packages/tmp/SFML-2.1/extlibs/libs-osx/lib/libGLEW.a
    -- Found JPEG: /Users/cdelorme/Documents/packages/tmp/SFML-2.1/extlibs/libs-osx/lib/libjpeg.a
    -- Found OpenAL: /System/Library/Frameworks/OpenAL.framework
    -- Found SNDFILE: /Users/cdelorme/Documents/packages/tmp/SFML-2.1/extlibs/libs-osx/Frameworks/sndfile.framework
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/cdelorme/Documents/packages/tmp/SFML-2.1


Then I tried to compile with `make` and I ran into this:

Code: [Select]


    make
    [  1%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o
    [  2%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Err.cpp.o
    [  3%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Lock.cpp.o
    [  4%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Mutex.cpp.o
    [  5%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Sleep.cpp.o
    [  6%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/String.cpp.o
    [  7%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Thread.cpp.o
    [  9%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/ThreadLocal.cpp.o
    [ 10%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Time.cpp.o
    [ 11%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/ClockImpl.cpp.o
    [ 12%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/MutexImpl.cpp.o
    [ 13%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/SleepImpl.cpp.o
    [ 14%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/ThreadImpl.cpp.o
    [ 15%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/ThreadLocalImpl.cpp.o
    Linking CXX shared library ../../../lib/libsfml-system.dylib
    [ 15%] Built target sfml-system
    [ 17%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Context.cpp.o
    [ 18%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/GlContext.cpp.o
    [ 19%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/GlResource.cpp.o
    [ 20%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Joystick.cpp.o
    [ 21%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/JoystickManager.cpp.o
    [ 22%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Keyboard.cpp.o
    [ 23%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Mouse.cpp.o
    [ 25%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/VideoMode.cpp.o
    [ 26%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Window.cpp.o
    [ 27%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/WindowImpl.cpp.o
    [ 28%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/cpp_objc_conversion.mm.o
    [ 29%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/cg_sf_conversion.cpp.o
    [ 30%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/InputImpl.mm.o
    /Users/cdelorme/Documents/packages/tmp/SFML-2.1/src/SFML/Window/OSX/InputImpl.mm: In function 'SFOpenGLView* sf::priv::getSFOpenGLViewFromSFMLWindow(const sf::Window&)':
    /Users/cdelorme/Documents/packages/tmp/SFML-2.1/src/SFML/Window/OSX/InputImpl.mm:79:30: error: expected ';' before 'in'
             for (NSView* subview in subviews) {
                                  ^
    /Users/cdelorme/Documents/packages/tmp/SFML-2.1/src/SFML/Window/OSX/InputImpl.mm:79:30: error: 'in' was not declared in this scope
    /Users/cdelorme/Documents/packages/tmp/SFML-2.1/src/SFML/Window/OSX/InputImpl.mm:79:33: error: expected ';' before 'subviews'
             for (NSView* subview in subviews) {
                                     ^
    make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/OSX/InputImpl.mm.o] Error 1
    make[1]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2
    make: *** [all] Error 2


So building it is unsuccessful, and I'm pretty sure this is an entirely unrelated problem.  I'd love to get it working, but I don't know if it makes sense to bring "How to build SFML on OSX 10.9.3 with homebrew'd gcc" into a topic about a bug in the apple clang compiler related to sf::String.  Should I open another thread for it?


I was able to compile with this command, leaving clang but setting the `-D_GLIBCXX_FULLY_DYNAMIC_STRING=1` flag:

Code: [Select]


    cmake -D CMAKE_CXX_FLAGS="-stdlib=libc++" -D CMAKE_C_FLAGS="-stdlib=libc++ -D_GLIBCXX_FULLY_DYNAMIC_STRING=1" -D CMAKE_OSX_ARCHITECTURES="x86_64" .


However, I continued to get the same errors when trying to run code that has an sf::String that was declared but never given a value.


---

@Hiura,

I'm sure it's a bug in apples compiler, and I also fully understand why no release is built against a non-apple gcc.  I do not understand why anyone would refuse to patch it.

It's a known bug, it has existed for over three years, and placing blame has solved **nothing**.  Fact is, SFML on OSX is effected, and in turn any developers on OSX are effected, and I haven't seen a logical reason like:

- It's a difficult bug that extends beyond the `sf::String` class.
- A patch could introduce erratic behavior or slow performance.
- Nobody has submitted a pull request for it that addresses these concerns.

I just do not follow the logic behind the "It's not my fault" reasoning of the discussion around this issue.  If not a code patch, how about a comment in the `sf::String` documentation so that developers are made aware of the problem?


---

For now I guess I'm stuck coding around this issue by instantiating all sf::String objects with a space because my environment of choice is being slighted. 

[Hiura]

So building it is unsuccessful, and I'm pretty sure this is an entirely unrelated problem.

Well, apparently GCC is not able to understand that .mm files are Objective-C++ code. Maybe have a look on the web to find out if it's a known issue or not. I can't help you.

a bug in the apple clang compiler

The bug is not in clang or gcc! It's libstdc++'s fault. You can try updating libstdc++ on your system if you want but you are definitely going to have huge issue with your users when distribution your app...

was able to compile with this command, leaving clang but setting the `-D_GLIBCXX_FULLY_DYNAMIC_STRING=1` flag:

You're defining _GLIBCXX_FULLY_DYNAMIC_STRING but at the same time you're using clang + libc++. That's useless.

I do not understand why anyone would refuse to patch it.

Ask Apple's dev team. It's a bug on their side. If SFML were to patch every bug to work with any combination of OS, compiler, driver, ... we would end up with a HUGE mess.

and I haven't seen a logical reason like:

- It's a difficult bug that extends beyond the `sf::String` class.
- A patch could introduce erratic behavior or slow performance.

1/ Reimplementing all basic_string functionality to work with a std::vector of char IS hard, painful, and only concern <1% of SFML users and will continue to decrease with time since Apple chose to use clang/libc++ instead. It would be crazy to spend so much time on this task (and even I wanted to patch it, I have clearly not enough free time).
2/ Yes, bad performance would be introduced with such a patch. Maybe also a few bugs. Can you implement string functions as fast as the stl implementation already provided? I can't.

I just do not follow the logic behind the "It's not my fault" reasoning of the discussion around this issue.

I think I already answered this a few line above. But take my place (or the place of any SFML team member) for a sec'. You have limited time resources and more importantly you have to think about long term development. Fixing corner case like this one when it's not SFML fault is a no-go for code maintenance and stability (e.g. performance).

If not a code patch, how about a comment in the `sf::String` documentation so that developers are made aware of the problem?

It would be overkill and defeat the purpose of the doc to add a comment for each problem like this one: you'll end up with a huge documentation text that barely talks about how to use SFML and its features. Instead, the bug tracker is more appropriate.

I hope you can understand my point of view.

[cdelorme]

I love SFML and these forums.  Everyone here has been very helpful and responsive.  I hope that I can eventually be a contributor and not just that guy who asks annoying questions.

@Hiura, you are fabulous.  Thank you for taking the time to give me a comprehensive answer and sharing your view.  I have no reason to press further on this.

---

Since attempting to build SFML though I have run into a new problem.  I removed the built code and re-added the prebuilt libraries, and now I can no-longer compile any of my sfml code.  I'm getting segfault 11's when I try running compiled code, or errors like this one when I try to compile:

Code: [Select]


    Undefined symbols for architecture x86_64:
      "sf::String::String(char const*, std::locale const&)", referenced from:
          _main in 42.o
    ld: symbol(s) not found for architecture x86_64
    collect2: error: ld returned 1 exit status
    ./compile: line 82: ./42: No such file or directory


Any idea what I broke and how I can undo it?

[Hiura]

Yes, I do know what you did wrong. It's a very common pitfall and is in red in the getting started tutorial for OS X.

In short, you've built SFML with different settings that your project. This especially concerns the STL lib you're using. If you compile SFML with `-stdlib=libc++` make sure your project use it, too.