SFML Not Drawing to Persistant/Static Window, Seg Faulting

[jeffclune]

Hello all,

I'd really appreciate your help with an SFML issue. It is crashing on me, and I'd either like to figure out how to solve the crash, or learn of a workaround.

I use SFML (v1.6) to create a window to draw openGL objects (very similar to EndlessForms.com, but on my computer).

I display 9 objects, get user feedback, then want to display 9 more. The draw() function that creates the SFML window is many levels deep in my code, and the way the architecture is set up, I have to leave that deep draw() function to do some processing to generate the next round of objects. Right now that works by creating a new window every time I want to display objects (with the window being reaped when leaving the draw() function). That creates a very distracting flicker every time the window is closed and opened, so what I want is a persistent window to stay open that I can just clear and draw new objects to for each iteration.

So, I attempted to do this:

sf::RenderWindow App (sf::VideoMode(windowWidth, windowHeight, 32), "Evolving 3D objects");

First time through that works as normal, when I leave draw() the window remains open, but when I come back to draw() none of my objects show up. What is interesting is that all of the functionality of the window still works (I can still click on objects, get the feedback, and proceed to the next iteration): I just can't see anything but a black screen.

That makes me think that the window is not being cleared or reset properly. So I tried

App.Clear() <-- which crashes the program via seg fault.

I searched around and see lots of people having App.Clear() crashing their programs, but the solution there (to recompile) doesn't make sense since I am on OS X and don't actually compile anything ahead of time.

Any ideas? Would App.clear() work if it didn't crash? Is there something else I should be doing that would work?

In case it helps, here are relevant portions of the seg fault error:

Process:         v2Hyperneat [82557]
Identifier:      v2Hyperneat
Version:         ()
Code Type:       X86 (Native)
Parent Process:  bash [82556]

Date/Time:       2012-02-16 14:06:50.047 -0500
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          503575 sec
Crashes Since Last Report:           17
Per-App Crashes Since Last Report:   17

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000044480014
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   com.sfml.graphics                0x005bdba8 sf::RenderTarget::Clear(sf::Color const&) + 40
1   v2Hyperneat                      0x000f0be7 HCUBE::ShapesExperiment::drawShapes(__gnu_debug_def::vector<CMesh, std::allocator<CMesh> >, int) + 911 (HCUBE_ShapesExperiment.cpp:856)

Thanks for any assistance.
Jeff

[texus]

Right now that works by creating a new window every time I want to display objects

Is there any reason why you can't create a window at start up and just leave it open?

App.Clear() <-- which crashes the program via seg fault.

First you should test if the problem lies with App.Clear() or with your own code.

Try the code from the tutorial, does it crash on the Clear function there?

Code: [Select]

int main()
{
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
   
    while (App.IsOpened())
    {
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }

        App.Clear();

        App.Display();
    }

    return EXIT_SUCCESS;
}

[Laurent]

What about trying SFML 2?

[jeffclune]

Is there any reason why you can't create a window at start up and just leave it open?

That is what I am effectively doing with the static App variable, no? At least, that is what I am trying to do. I also tried making it a global variable, but it had the same effect (both the App.Clear() crash, and the black screen with no redraw the second time around).

First you should test if the problem lies with App.Clear() or with your own code.

Try the code from the tutorial, does it crash on the Clear function there?

Code: [Select]

int main()
{
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");
   
    while (App.IsOpened())
    {
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }

        App.Clear();

        App.Display();
    }

    return EXIT_SUCCESS;
}

I just tried that. It seg faults on App.Clear(), but does not crash without App.Clear(). In other words, the crash problem at least is not with my code. Any ideas? Thanks for your help and suggestions.

[jeffclune]

What about trying SFML 2?

I thought about that. Does anyone know if this App.Clear bug is fixed in 2.0? Moreover, does anyone expect that App.Clear() would actually reset the window such that my drawing of the OpenGL objects the second time around would actually show up?

The reason I didn't dive right in and try 2.0 is because the v1.6 Mac OS X downloads don't require any compilation, but the v2.0 looks like it is completely different and requires a lot of complex compilation steps/libs/etc. I  can try it if people think that is likely to solve the problem, but was hoping that/wondering if others know of a fix or workaround...or at least that 2.0 is unlikely to have this bug/crash.

Thanks all for your suggestions.

[Laurent]

I'm not the OS X guy so I can't tell you if this is a known bug with 1.6, or if it's fixed in 2.0. But 2.0 is actively supported (the 1.6 OS X maintainer no longer works on SFML), and is less likely to have such bugs.

the v2.0 looks like it is completely different and requires a lot of complex compilation steps/libs/etc

Nop. It's very easy. You think it's complex because you haven't tried yet

[Hiura]

No such bug is known in SFML 2.0 so you should give it a try. Like Laurent said, it's very easy to compile SFML; just follow the cmake tutorial and everything should be allright.

SFML 2.0 on Mac is (mostly) built from scratch so if any bug like this one exists with 1.6 there is only little probabilities that it exists also with 2.0. And if it happens to exist then I will be happy to fix it.

[jeffclune]

No such bug is known in SFML 2.0 so you should give it a try. Like Laurent said, it's very easy to compile SFML; just follow the cmake tutorial and everything should be allright.

SFML 2.0 on Mac is (mostly) built from scratch so if any bug like this one exists with 1.6 there is only little probabilities that it exists also with 2.0. And if it happens to exist then I will be happy to fix it.

Great. Thanks to both of you. I'll give 2.0 a try and let you know how it goes.

[jeffclune]

the v2.0 looks like it is completely different and requires a lot of complex compilation steps/libs/etc

Nop. It's very easy. You think it's complex because you haven't tried yet

Ok. You were right. Compiling 2.0 is very easy. I then had to port some of my code to the new API, which was not that bad. LINKING, on the other hand, has proven to be very difficult. Right now I get the following errors (this is only a subset, but you get the idea). Note that the project I am using SFML in is being built for the i386 architecture. I tried setting CMAKE_OSX_ARCHITECTURES to i386 for SFML, but then it didn't compile. Any ideas?

ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-audio.framework/sfml-audio, file was built for unsupported file format which is not the architecture being linked (i386)


ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-graphics.framework/sfml-graphics, file was built for unsupported file format which is not the architecture being linked (i386)


ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-network.framework/sfml-network, file was built for unsupported file format which is not the architecture being linked (i386)


ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-system.framework/sfml-system, file was built for unsupported file format which is not the architecture being linked (i386)


ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-window.framework/sfml-window, file was built for unsupported file format which is not the architecture being linked (i386)


ld: warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/SFML.framework/SFML, file was built for unsupported file format which is not the architecture being linked (i386)


  "sf::RenderWindow::RenderWindow(sf::VideoMode, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, sf::ContextSettings const&)", referenced from:


      HCUBE::ShapesExperiment::drawShapes(__gnu_debug_def::vector<CMesh, std::allocator<CMesh> >, int)in HCUBE_ShapesExperiment.o


  "sf::Font::Font()", referenced from:


      HCUBE::ShapesExperiment::drawShapes(__gnu_debug_def::vector<CMesh, std::allocator<CMesh> >, int)in HCUBE_ShapesExperiment.o


  "sf::Font::~Font()", referenced from:


      HCUBE::ShapesExperiment::drawShapes(__gnu_debug_def::vector<CMesh, std::allocator<CMesh> >, int)in HCUBE_ShapesExperiment.o


  "sf::Window::Close()", referenced from:


      HCUBE::ShapesExperiment::drawShapes(__gnu_debug_def::vector<CMesh, std::allocator<CMesh> >, int)in HCUBE_ShapesExperiment.o


  "sf::Sprite::Sprite(sf::Texture const&)", referenced from:


      HCUBE::ShapesExperiment::drawShapes(__gnu_debug_def::vector<CMesh, std::allocator<CMesh> >, int)in HCUBE_ShapesExperiment.o


  "vtable for sf::Text", referenced from:


      __ZTVN2sf4TextE$non_lazy_ptr in HCUBE_ShapesExperiment.o


     (maybe you meant: __ZTVN2sf4TextE$non_lazy_ptr)

[jeffclune]

No such bug is known in SFML 2.0 so you should give it a try. Like Laurent said, it's very easy to compile SFML; just follow the cmake tutorial and everything should be allright.

SFML 2.0 on Mac is (mostly) built from scratch so if any bug like this one exists with 1.6 there is only little probabilities that it exists also with 2.0. And if it happens to exist then I will be happy to fix it.

PS. I should note that I saw that many others on the forum had similar linking errors, but I tried all of the solutions that were proposed and I am still getting this error. Any ideas?

[Hiura]

I saw that many others on the forum had similar linking errors

Really ? Who/Where ?

I am using SFML in is being built for the i386 architecture.

Why not using a universal binary ? It's way more convenient if you want your apps to run on the new macs which are 64bits.

/Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-audio.framework

How did you install SFML ? Did you put some stuff in this SDK ?

I tried setting CMAKE_OSX_ARCHITECTURES to i386 for SFML, but then it didn't compile.

it refers to SFML or your own project ?

[jeffclune]

I saw that many others on the forum had similar linking errors

Really ? Who/Where ?

Maybe I misspoke. I saw many having similar error messages, but it seems they were getting them when trying to build SFML, not when using the SFML libs/frameworks. Here is an example:

http://www.sfml-dev.org/forum/viewtopic.php?p=36210&sid=9d736971b8d126d675779e83f4de3d54

Why not using a universal binary ? It's way more convenient if you want your apps to run on the new macs which are 64bits.

The package I am building doesn't compile when I switch it away from i386 to 64 bits. That's because some of the libraries it uses are not 64 bit. Months ago I tried to update those libraries, but it quickly turned into a quagmire and I punted. It reminded me of this!

http://xkcd.com/456/

/Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/sfml-audio.framework

How did you install SFML ? Did you put some stuff in this SDK ?

I first tried byt not installing and using the libs that were placed in the build directory, and then I tried deleting the 1.6 SFML frameworks from /Library/Frameworks and doing a make install. Then I dragged in the SFML frameworks (SFML.framework, sfml-window.framework, etc.) from /Library/Frameworks. I checked that SDK and it does have the SFML 2.0 Frameworks, so maybe make install put it there too? The reason I know it has 2.0 is because of tis:

$ls /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/SFML.framework/Versions/
2.0.0/   Current@

I tried setting CMAKE_OSX_ARCHITECTURES to i386 for SFML, but then it didn't compile.

it refers to SFML or your own project ?[/quote]

No. It refers to SFML 2.0. It compiles when I leave CMAKE_OSX_ARCHITECTURES blank, but when I put i386 in there it produces this:


$make
[  2%] Built target SFML
[ 18%] Built target sfml-system
[ 46%] Built target sfml-window
[ 57%] Built target sfml-network
Linking CXX shared library ../../../lib/sfml-graphics.framework/Versions/2.0.0/sfml-graphics
ld: warning: in /opt/local/lib/libfreetype.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /Developer/SDKs/MacOSX10.6.sdk/usr/local/lib/libz.a, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
  "_FT_Open_Face", referenced from:


That is the issue being seen here: http://www.sfml-dev.org/forum/viewtopic.php?p=36210&sid=9d736971b8d126d675779e83f4de3d54

There is a solution mentioned at the bottom, but I don't now how to implement it. When you say "you can edit FREETYPE_LIBRARY to /usr/X11R6/lib/libfreetype.dylib and FREETYPE_INCLUDE_DIR_* should refer to extlibs/headers from SFML SDK.", how exactly do you do that?

So, what do you recommend? Trying to build SFML 2.0 in i386, or trying to link the universal SFML into my i386 package?

Thanks for your help.

[Hiura]

The package I am building doesn't compile when I switch it away from i386 to 64 bits. That's because some of the libraries it uses are not 64 bit. Months ago I tried to update those libraries, but it quickly turned into a quagmire and I punted. It reminded me of this!

It makes sens. Out of curiosity what libraries did you try to recompile ?

I first tried byt not installing and using the libs that were placed in the build directory, and then I tried deleting the 1.6 SFML frameworks from /Library/Frameworks and doing a make install. Then I dragged in the SFML frameworks (SFML.framework, sfml-window.framework, etc.) from /Library/Frameworks. I checked that SDK and it does have the SFML 2.0 Frameworks, so maybe make install put it there too?

Ok so you did a lot of stuff here. Get your system free from SFML binaries and just "make install" when the compilation is done/successful.

[make] install
Installs SFML to the path defined in the CMAKE_INSTALL_PREFIX and CMAKE_INSTALL_FRAMEWORK_PREFIX options. It copies the SFML libraries and headers, as well as examples and documentation if the BUILD_EXAMPLES and BUILD_DOC options are enabled. After installing, you get a clean distribution of SFML, just as if you had downloaded the SDK or installed it from the system repositories.

There is a solution mentioned at the bottom, but I don't now how to implement it. When you say "you can edit FREETYPE_LIBRARY to /usr/X11R6/lib/libfreetype.dylib and FREETYPE_INCLUDE_DIR_* should refer to extlibs/headers from SFML SDK.", how exactly do you do that?

In cmake-gui, check the "advanced" checkbox and find FREETYPE_LIBRARY then but /usr/X11R6/lib/libfreetype.dylib in the right column like you did for CMAKE_OSX_ARCHITECTURES. Set both FREETYPE_INCLUDE_DIR_freetype2 and FREETYPE_INCLUDE_DIR_ft2build variables to /path_to_your_sfml_directory/extlibs/headers.

So, what do you recommend? Trying to build SFML 2.0 in i386, or trying to link the universal SFML into my i386 package?

The best would be to use Universal binaries, at least for SFML : you will be able to provide 64bits support to your users and still use the same SFML binaries if you eventually succeed at recompiling the other dependencies.

[jeffclune]

Thank you. That worked! With 2.0 I was getting weird openGL effects, until I realized that the default Z/depth buffer was 24 in SFML-v1.6, but is set to 0 in SFML-2.0. That might trip a lot of others up, so you may want to switch the default or add some note to the documentation.

Thanks so much for your help.

[Hiura]

so you may want to switch the default or add some note to the documentation.

It's already written in the doc. Look at the default args of the ctor.

http://www.sfml-dev.org/documentation/2.0/structsf_1_1ContextSettings.php#aafe35f8e257f9d1e496ed64e33e2ee9f